[ovs-dev] [PATCH] dpif-linux: Choose port numbers more prudently.

Ben Pfaff blp at nicira.com
Wed Apr 6 02:46:25 UTC 2011

On Tue, Apr 05, 2011 at 06:08:23PM -0700, Ethan Jackson wrote:
> >    I think that we can avoid the loop with a 1024-bit bitmap.  That's
> >    only 128 bytes, which is small change next to the 2048-byte
> >    lru_ports array, so I think that we might as well do it.  We
> >    already have bitmap helpers in bitmap.h, so it should be really
> >    easy to do.
> That's a good point.  I want to get this patch in relatively quickly,
> but I will make an XXX note to do it that way and write a patch in the
> near term future which converts it.


> >    If there are no ports in the LRU and the port add fails with EBUSY,
> >    then dpif_linux_port_add() is likely to loop forever.
> My reading may be incorrect, but I don't think this is true.  If there
> are no ports in the LRU then the request will send UINT32_MAX.  In
> this case the kernel will choose a port.  If the kernel can't choose a
> port it fails with EFBIG not EFBUSY.  Are we worried about that
> interface changing?  At any rate I will just have it not loop again if
> UINT32_MAX was used.

It's not likely to happen, since there's nothing now that returns
EBUSY.  But what happens when someone introduces a kernel bug that
causes that to happen?  I want to hedge against that.

> >    I'd suggest trying again also if the error is EFBIG.  That means
> >    that the port number we requested is too big.  (Maybe someone
> >    reduced the number of supported datapath ports to save memory.)
> > In dpif_linux_port_del(), I would push the port only if the deletion
> > returns 0 (possibly also if it returns ENOENT to indicate that there's
> > no such port).
> I would think that it's safer to always push it.  If there was an
> error and the port is still installed, it will get removed from the
> queue when it EBUSYs in port_add.  I'll go ahead and change it though.


More information about the dev mailing list