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.
OK. > > 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. Thanks. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
