I currently do not have a real scenario where I have run into this problem.
However, it is easy to see real scenarios where I could run into this. As you said, most flows start off with a single packet and wait for a response. But, there is also the flow eviction mechanism which would bring this into play mid-flow. There is also the UDP traffic which does not have a ramp up mechanism. Yes, the window is small. But, I think it is real and could problems for some applications. -Joji On Thu, Apr 26, 2012 at 10:22 PM, Ben Pfaff <b...@nicira.com> wrote: > It isn't commonly a problem in practice because flows most often start > off with a single packet and wait for a return packet before ramping up > packet volume. I've been aware of the issue for years, but you are the > only other person I ever recall bringing it up on the mailing lists. > > Do you have a real situation (not a hypothetical scenario) where you see > this causing trouble? > > On Fri, Apr 27, 2012 at 11:06:29AM +0600, junaid khalid wrote: > > Are you planning to solve this problem in near future or do you have any > > suggestions to mitigate this problem? > > > > On Thu, Apr 26, 2012 at 2:37 AM, Ben Pfaff <b...@nicira.com> wrote: > > > > > On Wed, Apr 25, 2012 at 01:33:56PM -0700, Joji Mtt wrote: > > > > I am trying to figure out if there would be a packet order issue > with the > > > > current version of OVS. Consider a case where a controller has added > a > > > > forwarding rule for a specific flow (Flow A) and this rule is not yet > > > > installed in the DP. In this scenario, it is conceivable that certain > > > > (bursty) traffic patterns on Flow A can result in the packets being > sent > > > > out of order. E.g. consider an initial burst of 5 packets that miss > the > > > > kernel flow table, followed by several subsequent packets arriving at > > > > random intervals. As soon as the userspace processes the flow miss, > it > > > will > > > > install a rule in the kernel. Depending on the relative timing of the > > > rule > > > > installation, any of these subsequent packets could get switched > directly > > > > by the kernel before the previous packets that took the slow path > could > > > get > > > > forwarded. I couldn't find any special handling to cover this case. > Most > > > > likely it is already handled and I am just missing the part where it > is > > > > done. Could anyone clarify this for me? > > > > > > Yes, it's possible to get out-of-order packets for this reason. > > > _______________________________________________ > > > discuss mailing list > > > discuss@openvswitch.org > > > http://openvswitch.org/mailman/listinfo/discuss > > > >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
