https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-627 OpenFlowPlugin <p>What I used<br/> -----------</p> <p>OpenFlow version: OF13<br/> Target OFP: OpenFlow plugin Lithium version<br/> Application: VTN Manager ("odl-vtn-manager-rest" feature)<br/> Problem RPC: add-flow RPC<br/> Tested branch: <a href="https://git.opendaylight.org/gerrit/#/c/35118/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/35118/</a></p> <p>What I observed<br/> ---------------</p> <p>I observed that add-flow RPC of the OFP-Li was slow to install flow entries into OpenFlow 1.3 switches.<br/> The rate was 2 flow entries to a switch per second.</p> <p>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.</p> <p>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 &lt;10:32:11,240&gt;, and &lt;10:32:11,742&gt;, respectively.</p> <p>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<br/> 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=</p> {DL_SRC=ba:75:46:84:50:34,DL_DST=ea:ed:67:13:85:06,DL_VLAN=0} <p>, actions=</p> {OUTPUT(port=openflow:3:1, len=65535)} <p>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<br/> 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=</p> {DL_SRC=96:99:b7:12:c6:95,DL_DST=ba:75:46:84:50:34,DL_VLAN=0} <p>, actions=</p> {OUTPUT(port=openflow:3:3, len=65535)} <p>The issue is not occurred with the OpenFlow plugin Helium version.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-627

OFP-Li: add-flow RPC is slow; 2 flow entries per sec.

Bug Resolved Cannot Reproduce Unassigned Hideyuki Tai Thu, 25 Feb 2016 02:15:46 +0000 Mon, 27 Sep 2021 09:01:44 +0000 Fri, 26 Feb 2016 22:25:47 +0000 General 0 3 <p>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.</p> <p><span class="error">&#91;Example sequence&#93;</span></p> <p> 1. add-flow RPC is called for the flow entry A into the switch X<br/> 2. add-flow RPC is called for the flow entry B into the switch X<br/> 3. add-flow RPC is called for the flow entry C into the switch X</p> <p> 4. OFP-Li sends FLOW_MOD for the entry A<br/> 5. OFP-Li sends BARRIER_REQUEST<br/> 6. OFP-Li wants for the BARRIER_REPLY<br/> 7. OFP-Li receives the BARRIER_REPLY<br/> 8. OFP-Li completes the RPC for the entry A</p> <p> 9. OFP-Li sends FLOW_MOD for the entry B<br/> 10. OFP-Li sends BARRIER_REQUEST<br/> 11. OFP-Li wants for the BARRIER_REPLY<br/> 12. OFP-Li receives the BARRIER_REPLY<br/> 13. OFP-Li completes the RPC for the entry B</p> <p>14. OFP-Li sends FLOW_MOD for the entry C<br/> 15. OFP-Li sends BARRIER_REQUEST<br/> 16. OFP-Li wants for the BARRIER_REPLY<br/> 17. OFP-Li receives the BARRIER_REPLY<br/> 18. OFP-Li completes the RPC for the entry C</p> <p>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.</p> <p>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)?</p> <p>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.<br/> In other words, I think it doesn't need to wait until the OFP-Li receives the BARRIER_REPLY message for another add-RPC.<br/> The following example explains my exception.</p> <p><span class="error">&#91;Example sequence&#93;</span></p> <p> 1. add-flow RPC is called for the flow entry A<br/> 2. add-flow RPC is called for the flow entry B<br/> 3. add-flow RPC is called for the flow entry C</p> <p> 4. OFP-Li sends FLOW_MOD for the entry A<br/> 5. OFP-Li sends FLOW_MOD for the entry B<br/> 6. OFP-Li sends FLOW_MOD for the entry C<br/> 7. OFP-Li sends BARRIER_REQUEST<br/> 8. OFP-Li wants for the BARRIER_REPLY<br/> 9. OFP-Li receives the BARRIER_REPLY<br/> 10. OFP-Li complets the RPC for the entry A<br/> 11. OFP-Li complets the RPC for the entry B<br/> 12. OFP-Li complets the RPC for the entry C</p> <p>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.<br/> But, please note, here, I'm not talking about this.<br/> 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.</p> <p>I've realized that the remark of the "Comment 1" of the bug report is wrong.</p> <p>And now I'm thinking that if the bug4671 is fixed, the rate of installing flow entries would be improved.<br/> <a href="https://bugs.opendaylight.org/show_bug.cgi?id=4671" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=4671</a><br/> So I've closed the bug report as "INVALID".</p> Development External issue ID 5426 External issue URL Priority Rank 0|i032bj: