On Wed, 2007-07-04 at 16:48 +0200, Patrick McHardy wrote: > Yes, although in both cases you have no guarantee how long its > going to take, someone else could be flooding the receive queue. > For userspace this is more likely to be a real problem though > since the kernel will keep processing the queue as long as packets > are in it, while userspace could be scheduled away.
Right, but in the case of wireless you'll have different problems if that happens, namely your wireless card won't be reassociating etc. I don't think it'll be a problem in practice. > I'm not so sure myself whether netlink is really a good idea for > userspace<->userspace communication because of the above reason. > IIRC Herbert had the same doubts some time ago, I wonder what > made him change his mind. Hm. The reason I wanted it initially is that this way we can guarantee that userspace programs work in either case and also that we have better control over the various APIs. > There is a notifier for userspace unicast socket releases, would adding > another one for multicast groups help? Huh I think that notifier is enough in fact. It'll be called if a userspace process closes a socket or such, right? Might get a lot of events for generic netlink but that should be acceptable since it'd only need to check .pid to start with. johannes
signature.asc
Description: This is a digitally signed message part
