Re: [PATCH] xfrm: cache bundle lookup results in flow cache

["Timo Teräs" <timo.teras@iki.fi>]

Herbert Xu wrote:
> On Wed, Mar 17, 2010 at 04:16:21PM +0200, Timo Teräs wrote:
>> The problem is if I have multipoint gre1 and policy that says
>> "encrypt all gre in transport mode".
>>
>> Thus for each public address, I get one bundle. But the
>> xfrm_lookup() is called for each packet because ipgre_tunnel_xmit()
>> calls ip_route_output_key() on per-packet basis.
>>
>> For my use-case it makes a huge difference.
> 
> But if your traffic switches between those tunnels on each packet,
> we're back to square one, right?

Not to my understanding. Why would it change?

>> Then we cannot maintain policy use time. But if it's not a
>> requirement, we could drop the policy from cache.
> 
> I don't see why we can't maintain the policy use time if we did
> this, all you need is a back-pointer from the top xfrm_dst.

Sure.

>> Also. With this and your recent flowi patch, I'm seeing pmtu
>> issues. Seems like xfrm_bundle_ok uses the original dst which
>> resulted in the creation of the bundle. Somehow that dst
>> does not get updated with pmtu... but the new dst used in
>> next xfrm_lookup for same target does have proper mtu.
>> I'm debugging right now why this is happening. Any ideas?
> 
> The dynamic MTU is always maintained in a normal dst object in
> the IPv4 routing cache.  Each xfrm_dst points to such a dst
> through xdst->route.
> 
> If you were looking at the xfrm_dst's own MTU then that may well
> cause problems.

I figured the root cause. The original dst gets expired
rt_genid goes old. But xfrm_dst does not notice that so it
won't create a new bundle. xfrm_bundle_ok calls dst_check,
but dst->obsolete = 0, and ipv4_dst_check is a no-op anyway.

Somehow the rtable object should be able to tell back to
xfrm that the dst is not good anymore. Any ideas?

- Timo