From: Lorenzo Colitti <redacted>
Date: Thu, 20 Sep 2012 12:48:09 +0900
Sorry to butt in, but just to clarify - are you just saying that the
description should mention IPv6 explicitly, or is there something else
wrong with the patch?
If this patch makes IPv6 performance better without affecting IPv4, it's a
good idea to apply it anyway, right? IPv6 dst entry garbage collection can
potentially cause serious performance issues on any server with a public
IPv6 address, and this patch substantially improves the situation.
He's targetting net-next, and I've told him both in previous public
discussions and in recent private communication that the correct fix
is to make ipv6 routes use ref-count-less neighbour handling schemes
like ipv4.
This patch will not be applied as-is, it's not the correct way to fix
this problem.
On Thu, Sep 20, 2012 at 12:51 PM, David Miller [off-list ref] wrote:
quoted
If this patch makes IPv6 performance better without affecting IPv4, it's a
good idea to apply it anyway, right? IPv6 dst entry garbage collection can
potentially cause serious performance issues on any server with a public
IPv6 address, and this patch substantially improves the situation.
He's targetting net-next, and I've told him both in previous public
discussions and in recent private communication that the correct fix
is to make ipv6 routes use ref-count-less neighbour handling schemes
like ipv4.
Fair enough. Removing the cache is a better solution - requiring a
separate cache entry for every address you want to send a packet to is
not suited to a world where every user has 2^64 addresses or more. But
if removing the route cache for IPv6 is a large amount of work that
nobody will sign up for, then fixing the symptoms might be better than
nothing.
The performance degradation could become an attack vector. Of course
the people that run IPv6 servers today can maintain their own patches,
but that's sort of suboptimal.
Is there something else that can be done other than moving to
non-refcounted neighbours?