[OPNFLWPLUG-627] OFP-Li: add-flow RPC is slow; 2 flow entries per sec. Created: 25/Feb/16  Updated: 27/Sep/21  Resolved: 26/Feb/16

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Hideyuki Tai Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

External issue ID: 5426
Priority: High

 Description   

What I used
-----------

OpenFlow version: OF13
Target OFP: OpenFlow plugin Lithium version
Application: VTN Manager ("odl-vtn-manager-rest" feature)
Problem RPC: add-flow RPC
Tested branch: https://git.opendaylight.org/gerrit/#/c/35118/

What I observed
---------------

I observed that add-flow RPC of the OFP-Li was slow to install flow entries into OpenFlow 1.3 switches.
The rate was 2 flow entries to a switch per second.

In my observation, although the VTN Manager called many add-flow RPC for a switch to install many different flow entries at the same time concurrently, the OFP-Li installed the flow entries at exactly 0.5 second intervals.

For example, the following log messages in karaf.log show that the OFP-Li completed to install flow entries to the switch (openflow:3) at <10:32:11,240>, and <10:32:11,742>, respectively.

2016-02-24 10:32:11,240 (snip) - org.opendaylight.openflowplugin.impl - 0.2.1.SNAPSHOT | flow add finished without error, id=#UF$TABLE*0-35024
2016-02-24 10:32:11,241 (snip) - org.opendaylight.vtn.manager.implementation - 0.4.1.SNAPSHOT | Flow entry has been installed: flow=[id=7f56000000000076-1, pri=10, timeout=(0,0), node=openflow:3, ingress=openflow:3:3, cond=

{DL_SRC=ba:75:46:84:50:34,DL_DST=ea:ed:67:13:85:06,DL_VLAN=0}

, actions=

{OUTPUT(port=openflow:3:1, len=65535)}

2016-02-24 10:32:11,742 (snip) - org.opendaylight.openflowplugin.impl - 0.2.1.SNAPSHOT | flow add finished without error, id=#UF$TABLE*0-35026
2016-02-24 10:32:11,742 (snip) - org.opendaylight.vtn.manager.implementation - 0.4.1.SNAPSHOT | Flow entry has been installed: flow=[id=7f56000000000077-1, pri=10, timeout=(0,0), node=openflow:3, ingress=openflow:3:1, cond=

{DL_SRC=96:99:b7:12:c6:95,DL_DST=ba:75:46:84:50:34,DL_VLAN=0}

, actions=

{OUTPUT(port=openflow:3:3, len=65535)}

The issue is not occurred with the OpenFlow plugin Helium version.

 Comments   
Comment by Hideyuki Tai [ 25/Feb/16 ]

It seems to me that after the OFP-Li sends a BARRIER_REQUEST message for a FLOW_MOD message to a switch, the OPF-Li stops to process to send other FLOW_MOD messages to the switch until it receives the BARRIER_REPLY message from the switch.

[Example sequence]

1. add-flow RPC is called for the flow entry A into the switch X
2. add-flow RPC is called for the flow entry B into the switch X
3. add-flow RPC is called for the flow entry C into the switch X

4. OFP-Li sends FLOW_MOD for the entry A
5. OFP-Li sends BARRIER_REQUEST
6. OFP-Li wants for the BARRIER_REPLY
7. OFP-Li receives the BARRIER_REPLY
8. OFP-Li completes the RPC for the entry A

9. OFP-Li sends FLOW_MOD for the entry B
10. OFP-Li sends BARRIER_REQUEST
11. OFP-Li wants for the BARRIER_REPLY
12. OFP-Li receives the BARRIER_REPLY
13. OFP-Li completes the RPC for the entry B

14. OFP-Li sends FLOW_MOD for the entry C
15. OFP-Li sends BARRIER_REQUEST
16. OFP-Li wants for the BARRIER_REPLY
17. OFP-Li receives the BARRIER_REPLY
18. OFP-Li completes the RPC for the entry C

Since by default the OFP-Li sends BARRIER_REQUEST at 0.5 second intervals, it makes sense that I observed the rate of 2 flow entries per sec.

If my understanding is correct, is there any reason why the OFP-Li does not process to send other FLOW_MOD messages (in the above example, FLOW_MDO for the entry B and C) until it receives the BARRIER_REPLY message for another add-flow RPC call (in the above example add-flow RPC for the entry A)?

I have expected that when an application calls add-flow RPC multiple times for the same switch concurrently, the OFP-Li sends multiple FLOW_MOD messages to the switch immediately for all add-flow calls. It doesn't need to wait to send a FLOW_MOD message until another add-flow RPC completes.
In other words, I think it doesn't need to wait until the OFP-Li receives the BARRIER_REPLY message for another add-RPC.
The following example explains my exception.

[Example sequence]

1. add-flow RPC is called for the flow entry A
2. add-flow RPC is called for the flow entry B
3. add-flow RPC is called for the flow entry C

4. OFP-Li sends FLOW_MOD for the entry A
5. OFP-Li sends FLOW_MOD for the entry B
6. OFP-Li sends FLOW_MOD for the entry C
7. OFP-Li sends BARRIER_REQUEST
8. OFP-Li wants for the BARRIER_REPLY
9. OFP-Li receives the BARRIER_REPLY
10. OFP-Li complets the RPC for the entry A
11. OFP-Li complets the RPC for the entry B
12. OFP-Li complets the RPC for the entry C

I think that if an application sets the explicit barrier (I'm not sure if this expression is correct) on the add-flow call, the interval of the BARRIER_REQUEST becomes very short, so the rate of installing flow entries would be fast.
But, please note, here, I'm not talking about this.
In this bug report, I'm talking about why the OFP-Li does not process to send other FLOW_MOD messages until it receives the BARRIER_REPLY message for another add-flow RPC call.

Comment by Hideyuki Tai [ 26/Feb/16 ]

I've realized that the remark of the "Comment 1" of the bug report is wrong.

And now I'm thinking that if the bug4671 is fixed, the rate of installing flow entries would be improved.
https://bugs.opendaylight.org/show_bug.cgi?id=4671
So I've closed the bug report as "INVALID".

Generated at Wed Feb 07 20:32:58 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.