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]>
*Cc:* Robert Varga <[email protected]>; 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 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
