Taylor R Campbell <riastradh%NetBSD.org@localhost> writes: > This breaks the deadlock by making usbnet's SIOCADDMULTI/SIOCDELMULTI > never take the usbnet core lock. > > However, it may delay updating the hardware's multicast filter a > little bit -- the filter won't be updated synchronously by the time > if_mcast_op returns. > > Is this delay a problem? > > I would assume no -- it seems like the worst possible outcome is that > we might lose a race with a few packets that get dropped on the floor > because the hardware's multicast filter wasn't told to accept them > yet, or we might lose a race and get a few packets that the hardware > was supposed to ignore, but neither of these seems particularly bad to > me. > > But I don't understand this stuff very well so perhaps my assessment > is wrong. I think that's fine, more or less. There's no guarantee that when you get a completion from the filter write to the hardware that the computer on the other side of the bus has actually done what it is supposed to do. If we care that the ioctl hasn't returned until the hardware has said it's done, then the ioctls should probably be broken into 3 parts, but that seems like a lot of work for no reason. Typically multicast join/leave is something that happens over at least timescales of seconds. It might be nice to guarantee that ioctl(SIOCADDMULTI) sendto() results in the multicast add happening before the packet, so that the response that arrives (which is mcast) 500 us later is accepted. I don't know if that's a big deal in practice
Attachment:
signature.asc
Description: PGP signature