[ovs-dev] [PATCH] dpif-linux: Choose port numbers more prudently.
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