[ovs-discuss] packet reorderoing

Gray, Mark D mark.d.gray at intel.com
Wed Mar 4 17:05:33 UTC 2015


> From: Ben Pfaff [mailto:blp at nicira.com]
> Sent: Wednesday, March 4, 2015 4:59 PM
> 
> On Wed, Mar 04, 2015 at 04:53:45PM +0000, Gray, Mark D wrote:
> > > From: Ben Pfaff [mailto:blp at nicira.com]
> > > Sent: Wednesday, March 4, 2015 4:51 PM On Wed, Mar 04, 2015 at
> > > 04:42:36PM +0000, Gray, Mark D wrote:
> > > > >
> > > > > On Wed, Feb 25, 2015 at 11:28:56AM -0600, swair shah wrote:
> > > > > > When packets which does not match any rule in ovs, are
> > > > > > buffered at the ingress switch, say first n packets are
> > > > > > buffered. Switch sends a flow_mod and message and packet_out
> > > > > > for the buffered packets, meanwhile if some more packets of
> > > > > > the same flow arrive (say n+1 to m), they'll also get buffered (as
> flow_mod) hasn't arrived yet.
> > > > > >
> > > > > > Once flow_mod message arrives at the switch then subsequent
> > > > > > packets of the flow will be forwarded but packets (n+1 to m)
> > > > > > will still be buffered waiting for their packet_outs. This
> > > > > > results in reordering of
> > > > > packets.
> > > > > >
> > > > > > Is there a way around this, besides from proactively setting up a
> flow?
> > > > > >
> > > > > > Is there a way to match flow_mod to existing buffered packets?
> > > > >
> > > > > Reordering can happen.  There isn't a way to avoid it entirely
> > > > > (besides proactive flow setup).  It isn't usually a problem,
> > > > > though, because most protocols only send one packet before they
> > > > > receive a reply from the opposite end.
> > > >
> > > > The only way that I can think to nail up a flow is via dpctl. Is
> > > > this how you suggest to do this?
> > >
> > > Can you be more specific about what you want to do?  I can think of
> > > a few possibilities.
> >
> > I don't know what Swair wants but I would like to be certain to avoid
> > reordering of packets traversing the vswitch. I suspect the way to do
> > this is to add a flow into the datapath and make it persistent so that
> > upcalls are never triggered.
> 
> I don't see how that can solve the problem that he is reporting.  Did you read
> his whole scenario?  If we knew how to handle the packet in the datapath at
> the beginning of the scenario then we would not be sending it to the
> controller.

I see the confusion, he is referring to using a controller and it not matching the
switch, I am thinking of missing the datapath. My bad ..
> 
> I doubt that this is a real problem that needs to be solved, because it's been
> in the back of my mind since about 2008 as a possible concern but this is the

It has been a concern of mine for a while and I also expected it to come
up at some stage but it never did. I don't think it is an issue in most cloud
deployments but could see it be an issue in NFV deployments as usually
there would be an expectation that a router or another network
element wouldn't reorder.

However, hypothetically, how would you resolve this?

> first time I remember anyone actually voicing it.  Swair hasn't explained how
> it actually shows up as a problem in practice.
> Swair?
> 
> (Also, this particular manifestation of the issue can only occur with reactive
> controllers, which don't scale.)



More information about the discuss mailing list