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-574 OpenFlowPlugin <p>We are adding flow to MD-SAL data store (FRM) with barrier=true for the flows. Analyzing the OF packet flow to the switch, we do not see the barrier request/reply being sent out to the switch.</p> <p>To reproduce, start mininet, add a flow with the barrier attribute set to true and observe the OF Protocol to the switch. Barrier message will not be sent.</p> <p>Note that the Li plugin sends out a lot of barriers, but not when asked by the user to send one before / after a flow that the user wants to synchronize.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-574

Li Migration: barrier=true does not seem to be sending a barrier message

Bug Resolved Won't Do Unassigned Jan Medved Wed, 25 Nov 2015 05:30:03 +0000 Mon, 27 Sep 2021 09:01:40 +0000 Thu, 21 Jul 2016 16:11:26 +0000 General 0 3 <p>For Li-design the barrier flag by flow, group and meter is ignored because you can wait in the invoking code for the future result or particular rpc. Or you can hook a callback or chain another future using Futures.transform(..).</p> <p>Anyway there is service designed for explicit barrier sending:</p> <p>(you need rpcBroker in order to get the service proxy and instanceIdentifier of target device node)</p> <p>final FlowCapableTransactionService barrierService = <br/> getRpcRegistryDependency().getRpcService(FlowCapableTransactionService.class);</p> <p>final SendBarrierInput barrierInput = new SendBarrierInputBuilder()<br/> .setNode(new NodeRef(nodeInstanceIdentifier)).build();</p> <p>final Future&lt;RpcResult&lt;Void&gt;&gt; rpcResultFuture = <br/> barrierService.sendBarrier(barrierInput);</p> <p>Now again you need to wait for result as this call is asynchronous too.</p> <p>(In reply to michal rehak from comment #1)<br/> &gt; For Li-design the barrier flag by flow, group and meter is ignored because<br/> &gt; you can wait in the invoking code for the future result or particular rpc.<br/> &gt; Or you can hook a callback or chain another future using<br/> &gt; Futures.transform(..).</p> <p>We've also confirmed that the OpenFlow Plugin Li design ignores the barrier flag in the input for add-flow RPC and remove-flow RPC.</p> <p>I think this is a bug, so should be fixed. The OpenFlow Plugin Lithium design should not ignore the barrier flag, since there is no reason to ignore the flag. When an application asks the plugin to send a BARRIER_REQUEST, the plugin should send the BARRIER_REQUEST immediately after a FLOW_MOD.</p> <p>I think waiting for the future result or hooking a callback is not related to the problem here.</p> <p>Hi Hideyuki,<br/> in He-design rpc futures get completed upon message sent by netty. <br/> In Li-design rpc futures get completed when:</p> <ul class="alternate" type="square"> <li>corresponding error arrives</li> <li>or reply (if protocol defines it)</li> <li>or upon subsequent barrier reply (barrier request was sent after the rpc message)</li> </ul> <p>Of course it takes more time for rpc in Li to complete. But the result contains all the relevant info and app can rely in that.</p> <p>Appending an explicit barrier to flow/meter/group will cause that completion might happen earlier (up to 500ms). Otherwise there is always an automatic barrier sent in order to flush all outstanding rpcs. This automatic barrier is optimized so that it is not being sent too often.</p> <p>In nutshell: if you need to be sure that previous flow is installed on device you either need to wait for subsequent barrier reply or wait for statistics. I understand that in He-design the future from rpc gets completed very fast. But on app side it is not possible to control. Attaching barrier in He-design is the only way how to be sure that device processing is completed.<br/> In Li-design this is done by design and if you need explicit barrier in order to speed up a bit even by taking the risk of flooding device with barriers then you can do so by invoking appropriate rpc. All you need to do is to invoke barrier rpc in the same thread in which you invoked the previous rpc.</p> <p>(In reply to michal rehak from comment #3)<br/> &gt; Hi Hideyuki,<br/> &gt; in He-design rpc futures get completed upon message sent by netty. <br/> &gt; In Li-design rpc futures get completed when:<br/> &gt; - corresponding error arrives <br/> &gt; - or reply (if protocol defines it) <br/> &gt; - or upon subsequent barrier reply (barrier request was sent after the rpc<br/> &gt; message)<br/> &gt; <br/> &gt; Of course it takes more time for rpc in Li to complete. But the result<br/> &gt; contains all the relevant info and app can rely in that.<br/> &gt; <br/> &gt; Appending an explicit barrier to flow/meter/group will cause that completion<br/> &gt; might happen earlier (up to 500ms). Otherwise there is always an automatic<br/> &gt; barrier sent in order to flush all outstanding rpcs. This automatic barrier<br/> &gt; is optimized so that it is not being sent too often.<br/> &gt; <br/> &gt; In nutshell: if you need to be sure that previous flow is installed on<br/> &gt; device you either need to wait for subsequent barrier reply or wait for<br/> &gt; statistics. I understand that in He-design the future from rpc gets<br/> &gt; completed very fast. But on app side it is not possible to control.<br/> &gt; Attaching barrier in He-design is the only way how to be sure that device<br/> &gt; processing is completed.<br/> &gt; In Li-design this is done by design and if you need explicit barrier in<br/> &gt; order to speed up a bit even by taking the risk of flooding device with<br/> &gt; barriers then you can do so by invoking appropriate rpc. All you need to do<br/> &gt; is to invoke barrier rpc in the same thread in which you invoked the<br/> &gt; previous rpc.</p> <p>Hi Michal,</p> <p>Thank you for your comment!</p> <p>My understanding about "when RPC futures get completed" in the Li-design and He-Design is the same with what you explained here.</p> <p>So do you suggest VTN Project should use the send-barrier RPC modeled in flow-capable-transaction.yang in the Li-design in Boron?<br/> If the OFP project continuously supports the send-barrier RPC in Boron, it would work fine for the VTN project.</p> <p>I've asked about this to the OFP project folks in the ML in March, but I've not received any responses about it yet.<br/> <a href="https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-March/004808.html" class="external-link" target="_blank" rel="nofollow noopener">https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-March/004808.html</a></p> <p>Barrier API (flow-capable-transaction.yang) shall stay with us at least till Carbon. And currently there is no plan to deprecate it.</p> <p>VTN blocked by this.</p> <p>Not a blocking issue for VTN any longer - as VTN has already implemented calling the send barrier RPC.</p> <p>No longer critical</p> Development External issue ID 4671 External issue URL ODL SR Target Milestone Priority Rank 0|i031zr: