| To: | jamal <hadi@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] rtnetlink & address family problem |
| From: | Thomas Graf <tgraf@xxxxxxx> |
| Date: | Tue, 7 Dec 2004 14:17:06 +0100 |
| Cc: | Michal Ludvig <mludvig@xxxxxxx>, Andrew Morton <akpm@xxxxxxxx>, Stephen Hemminger <shemminger@xxxxxxxx>, netdev@xxxxxxxxxxx, Jan Kara <jack@xxxxxxx> |
| In-reply-to: | <1102424568.1089.120.camel@jzny.localdomain> |
| References: | <41B0A5B4.6060108@suse.cz> <20041206140214.GA749@postel.suug.ch> <1102386461.1093.26.camel@jzny.localdomain> <20041207124922.GA1371@postel.suug.ch> <1102424568.1089.120.camel@jzny.localdomain> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
> > I don't think it is wrong myself but I understand if someone does. If > > one sends a GETADDR request for PF_INET6 one might expect to either > > receive all ipv6 addresses or none and to only receive all addresess > > of any type if PF_UNSPEC was specified. > > > > Thats debatable. > Its user space that issues the flushing after a response from the > kernel. It happens to be flushing IPV4 addresses. > Thats why your filter in ip is the answer. Agreed. > BTW, did the gnet_stats patches to iproute2 ever get merged? Not sure, I will check that. > If you have cycles, can you please look at that hang being reported > using older tc with 2.6.10-rc3? It's not really related to the gnet_stats code. stats_lock isn't set in the action code when using an older iproute2. I haven't tested this case because it was marked as broken anyway. I compiled an older version of iproute2 and will look into it today. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: _High_ CPU usage while routing (mostly) small UDP packets, Karsten Desler |
|---|---|
| Next by Date: | Re: [PATCH] rtnetlink & address family problem, jamal |
| Previous by Thread: | Re: [PATCH] rtnetlink & address family problem, jamal |
| Next by Thread: | Re: [PATCH] rtnetlink & address family problem, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |