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]> 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]] > *Sent:* Wednesday, February 24, 2016 03:32 > *To:* Tai, Hideyuki <[email protected]> > *Cc:* Abhijit Kumbhare <[email protected]>; > [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
