| 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. 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 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. 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 |
| Previous by Date: | Re: [PATCH] Improve behaviour of Netlink Sockets, Pablo Neira |
|---|---|
| Next by Date: | Re: [PATCH] Improve behaviour of Netlink Sockets, Pablo Neira |
| Previous by Thread: | Re: [PATCH] Improve behaviour of Netlink Sockets, Herbert Xu |
| Next by Thread: | Re: [PATCH] Improve behaviour of Netlink Sockets, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |