[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140426.000655.2286393147313574001.davem@davemloft.net>
Date: Sat, 26 Apr 2014 00:06:55 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: hannes@...essinduktion.org
Cc: clm@...com, netdev@...r.kernel.org
Subject: Re: [PATCH RFC] ipv6_fib limit spinlock hold times for
/proc/net/ipv6_route
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Fri, 25 Apr 2014 23:31:40 +0200
> On Thu, Apr 24, 2014 at 10:41:11AM -0400, Chris Mason wrote:
>> I was going to discuss the cache exclusion on a separate thread, but the
>> short version is that I don't have any clue of how many people we'd
>> upset by unconditionally leaving out the cached entries.
>
> In my opinion this would be ok.
>
> We definitely must reduce number of entries in the fib and I don't think it is
> wise to synthesize them thereafter, especially if we don't need to track state
> at all, e.g. forwarding.
I think this is a dangerous idea, to limit what is shown in the dumps.
We must always output the entry that would actually be used by a
lookup otherwise you are asking for impossible to debug scenerios.
On the other side, once we change ipv6 to work like ipv4, those cached
entries simply won't be there at all and then automatically this huge
dump issue just goes away.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists