netdev
[Top] [All Lists]

Re: [PATCH] Improve behaviour of Netlink Sockets

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] Improve behaviour of Netlink Sockets
From: Pablo Neira <pablo@xxxxxxxxxxx>
Date: Sun, 19 Sep 2004 22:50:25 +0200
Cc: davem@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20040919120730.GA6005@gondor.apana.org.au>
References: <414D0CCD.90209@eurodev.net> <E1C8way-0000aH-00@gondolin.me.apana.org.au> <20040919120249.GA5963@gondor.apana.org.au> <20040919120730.GA6005@gondor.apana.org.au>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.6) Gecko/20040528 Debian/1.6-7
Herbert Xu wrote:

In fact this is the reason why this whole problem is non-existant.

Unless there is a kernel user that sends netlink messages with a timeout
value other than 0, this patch does not resolve any dead-locks at all
since there is none to start with.


yes, you are totally right, but as I told you before, I'm not focusing my efforts in improving netlink sockets for tools like iproute, for those MSG_DONTWAIT is fairly ok.


So it looks to me as if this entire patch is simply papering over bugs
in the user-space application where it either isn't processing the
messages fast enough or it needs to enlarge its queue size.



I don't agree, enlarging the queue size for applications that send a lot of information in a short period of time is just a workaround.


Here is a tip, use separate sockets for unicast and multicast messages.
That way your unicast socket is very unlikely to overrun.

So I'd like to see the whole thing reverted.



Herbert, I don't agree, my patch isn't related to stuff that you've mentioned. It's fairly true that most çof application use socket timeout 0, but my patch is not for those! :-) well, still disagree?


regards,
Pablo

<Prev in Thread] Current Thread [Next in Thread>