[Top] [All Lists]

Re: [PATCH] Improve behaviour of Netlink Sockets

To: Pablo Neira <pablo@xxxxxxxxxxx>
Subject: Re: [PATCH] Improve behaviour of Netlink Sockets
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 20 Sep 2004 07:53:28 +1000
Cc: davem@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <414DF111.3080409@xxxxxxxxxxx>
References: <414D0CCD.90209@xxxxxxxxxxx> <E1C8way-0000aH-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20040919120249.GA5963@xxxxxxxxxxxxxxxxxxx> <20040919120730.GA6005@xxxxxxxxxxxxxxxxxxx> <414DF111.3080409@xxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Sun, Sep 19, 2004 at 10:50:25PM +0200, Pablo Neira wrote:
> 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.

No I'm talking not about iproute, I'm talking the kernel callers of
unicast/broadcast.  They never wait.
> 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.

Workaround for what? Please define your problem.

Your original message mentioned a dead-lock, which is now obviously

> 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?

Please reread my messages.  I'm not talking about user-space applications
setting timeout to 0.  Most of them don't.

I'm talking about every single kernel netlink sender.  They never wait.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

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