Re: [PATCH 2/3] xfrm: Increase the garbage collector threshold

[Steffen Klassert <steffen.klassert@secunet.com>]

On Fri, Dec 13, 2013 at 05:13:29PM +0100, Maxime Bizon wrote:
> 
> On Fri, 2013-12-13 at 11:12 +0100, Steffen Klassert wrote:
> 
> > Can you please be a bit more precise with your problem description?
> 
> yes sorry I wasn't clear.
> 
> I have a problem with an even simpler workload that the one using apache
> bench in the original bug report.
> 
> I am using ipsec transport mode between two hosts and just run this on
> one side:
> 
>   while :; do wget -O /dev/null http://remote_host/; done
> 
> I was surprised to see it fails after only 1024 requests (ENOBUF on
> connect), and how long I had to wait to be able to do new requests.
> 
> After debugging I saw that the xfrm gc was called but was not able to
> release anything.
> 
> after running "ip route flush cache", which forces all ipv4 dst entries
> to be released, suddenly the xfrm gc had something to free, and xfrm
> entry count went to zero.

Well, "ip route flush cache" bumps the rt_genid what marks all
routes as invalid. The xfrm garbage collector will notice this
on the next run and deletes all invalid cached routes.

Garbage collecting is different from flushing, it only removes
stale routes and keeps everything that was used recently. That's
the whole point of this caching, we cache recently used IPsec
routes to avoid a slow path lookup.

> 
> So if it is correct that once a ipv4 dst entry exists, the xfrm entry
> cannot be gc-ed, then we need to make sure we allow more xfrm entries to
> be allocated than ipv4 dst.

No, we don't cache plain ipv4 routes, we cache only IPsec routes.
The original ipv4 dst_entry is cached together with the xfrm dst_entry
as a xfrm bundle at the IPsec flow cache, so it does not make sense to
ensure something like that.