Hi Robert and other OF-Plugin project's contributors, It is about the send-barrier RPC modeled in flow-capable-transaction.yang, right?
Does the OF-Plugin project plan to support the send-barrier RPC in Boron? Does the OF-Plugin project not plan to continuously support the barrier flag in openflowplugin-li? If an application calls add-flow RPC firstly and send-barrier RPC secondly, does the openflowplugin-li definitely send a BARRIER_REQUEST after the FLOW_MOD for the add-flow RPC? I mean if the openflowplugin-li does not keep the order and it is possible that it sends the BARRIER_REQUEST before the FLOW_MOD, the send-barrier RPC does not work perfectly as expected. How about the barrier flag? Does the openflowplugin-li not plan to support the barrier flag? If not, I think the bug 4671 should be closed as an invalid bug. https://bugs.opendaylight.org/show_bug.cgi?id=4671 Best Regards, -- Hideyuki Tai Software Engineer NEC Corporation of America Office: +1-408-844-1012 Cell: +1-408-784-2147 Email: [email protected] From: Robert Varga [mailto:[email protected]] Sent: Saturday, March 05, 2016 02:55 To: Tai, Hideyuki <[email protected]>; Anil Vishnoi <[email protected]> Cc: Abhijit Kumbhare <[email protected]>; [email protected]; [email protected]; Kamal Rameshan (kramesha) <[email protected]> Subject: Re: [OpenDaylight TSC] OF-Plugin dependent projects migration plan to Li design in the service releases I think (without checking) the barrier flag is from the legacy API, the Li RPC API has an explicit barrier request message -- for which we do explicit checks here: https://github.com/opendaylight/openflowjava/blob/master/openflow-protocol-impl/src/main/java/org/opendaylight/openflowjava/protocol/impl/core/connection/OutboundQueueManager.java#L108 So if VTN sends these explicit barriers, everything will work as expected... Thanks, Robert On 2016-03-05 03:30, Tai, Hideyuki wrote: It would perfectly work fine for VTN project. Regards, Hideyuki Tai From: Anil Vishnoi [mailto:[email protected]] Sent: Friday, March 04, 2016 18:11 To: Tai, Hideyuki <[email protected]><mailto:[email protected]> Cc: Robert Varga <[email protected]><mailto:[email protected]>; Abhijit Kumbhare <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Kamal Rameshan (kramesha) <[email protected]><mailto:[email protected]> Subject: Re: [OpenDaylight TSC] OF-Plugin dependent projects migration plan to Li design in the service releases I think one possible solution is, if user use barrier flag, disregard the timeout & queue size threshold and flush the queue. On Fri, Mar 4, 2016 at 2:45 PM, Tai, Hideyuki <[email protected]<mailto:[email protected]>> wrote: Hi Robert, I'm sorry for the delayed response. I was not aware of your mail until now. Now, I think it was not appropriate to call that issue as a performance issue of the OF-Plugin Li design. Anyway, please let me explain that issue. [Short answer] VTN project needs a way to install a flow entry and get the result of the installation immediately after calling add-flow RPC. It means that VTN project wants the OFP-Li to provide a way to send a FLOW_MOD and a BARRIER_REQUEST immediately after an application calls the add-flow RPC. If I understand correctly, by default, OFP-Li sends BARRIER_REQUEST to a switch at 0.5 second intervals. Therefore, at the worst case, it would take 0.5 second that an application gets the result of the installation (BARRIER_REPLY) after it calls add-flow RPC. However, the 0.5 second is too long for some applications for some use cases. Therefore, for example, if the bug 4671 (add-flow RPC ignores barrier flag) is fixed, VTN project would be happy. https://bugs.opendaylight.org/show_bug.cgi?id=4671 (I'm not sure if fixing the bug 4671 is fine with the design principle of the OFP-Li.) [Long answer] The issue we are observing is that the flow installation throughput of VTN feature with the OFP-Li is much slower than with OFP-He. That's because (1) OFP-Li sends BARRIER_REQUEST at 0.5 second intervals by default and (2) the VTN feature installs an ingress flow entry after it confirms that the installation of core and egress flow entries is success. For example, let's think there are three OpenFlow switches and two hosts. Host1 - Switch1 - Switch2 - Switch3 - Host2 When VTN feature creates an end-to-end flow from Host1 to Host2, firstly the VTN feature calls add-flow RPC to install a flow entry into Switch2 (Core switch) and Switch3 (Egress switch). And, after the VTN feature confirms that these flow entries are successfully installed into these switches, it calls add-flow RPC to install a flow entry into Switch1 (Ingress switch). By doing this, the VTN feature avoids forwarding packets in unexpected ways. I mean the VTN feature installs ingress flow entries after it confirms that flow entries are successfully installed into core and egress switches. Therefore, now, by default, the VTN feature takes around 0.5 second to set up an end-to-end flow. That's why VTN wants the OFP-Li to provide a way to send a FLOW_MOD and a BARRIER_REQUEST immediately after an application calls add-flow RPC. I guess some other applications would face the same issue for different use cases. I discussed about this issue with Anil and Kamal in ODL Developer Design Forum in this week. So I think they would have some ideas around that issue. If I understand correctly, Anil has said that the design principle of the OFP-Li is to hide the concept of BARRIER_REQUEST/REPLY from applications. So he has said that the OFP-Li should not support the barrier flag in the input of add-flow RPC. Instead of the name "barrier flag", he has suggested that the add-flow RPC should introduce a new flag which means kind of to flush every messages in the outbound queue, anyway, it makes the OFP-Li sends FLOW_MOD and BARRIER_REQUEST immediately. (In that design principle, I think the OFP-Li should not support send-barrier RPC.) Kamal has explained that the interval time for periodic BARRIER_REQUEST is configurable. And, if I understand correctly, he has also explained that OFP-Li sends BARRIER_REQUEST when the number of FLOW_MOD it sent are over the threshold, and the threshold is also configurable. So if we configure the threshold to 1, the OFP-Li would send the BARRIER_REQUEST every time it sends FLOW_MOD. I think these configurable values are useful to applications for some use cases. But, in addition to these configurable values, I think it is better that OFP-Li also provides applications with more flexible ways, that is, a way to send BARRIER_REQUEST whenever applications wants, since I think some applications need to get the result of flow installation immediately for some types of flow entries, but the applications don't need to get the result for other types of flow entries. Best Regards, Hideyuki Tai From: Robert Varga [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, February 24, 2016 03:32 To: Tai, Hideyuki <[email protected]<mailto:[email protected]>> Cc: Abhijit Kumbhare <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [OpenDaylight TSC] OF-Plugin dependent projects migration plan to Li design in the service releases On 02/23/2016 07:31 PM, Abhijit Kumbhare wrote: • According to Hideyuki - VTN has already unmerged patch (https://git.opendaylight.org/gerrit/#/c/35118/) for the migration. However they have run into a performance issue when using the RPCs. Hello Hideyuki-san, can you provide some details on the performance problems, so we can take action and make sure they are fixed? Thanks, Robert -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
