> 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. > 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. Revised patch is forthcoming. Ethan _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
