Re: [PATCH RFC] net/ipv4: Use next hop exceptions also for input routes

[Timo Teras <timo.teras@iki.fi>]

On Sun, 26 May 2013 00:03:04 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Timo Teräs <timo.teras@iki.fi>
> Date: Thu, 23 May 2013 16:15:46 +0300
> 
> > Commit d2d68ba9 (ipv4: Cache input routes in fib_info nexthops)
> > assmued that "locally destined, and routed packets, never trigger
> > PMTU events or redirects that will be processed by us".
> > 
> > However, it seems that tunnel devices do trigger PMTU events in
> > certain cases. At least ip_gre, ip6_gre, sit, and ipip do use the
> > inner flow's skb_dst(skb)->ops->update_pmtu to propage mtu
> > information from the outer flows. These can cause the inner flow
> > mtu to be decreased. If next hop exceptions are not consulted for
> > pmtu, IP fragmentation will not be done properly for these routes.
> > 
> > It also seems that we really need to have the PMTU information
> > always for netfilter TCPMSS' clamp-to-pmtu feature to work properly.
> > 
> > So for the time being, cache separate copies of input routes for
> > each next hop exception.
> > 
> > Signed-off-by: Timo Teräs <timo.teras@iki.fi>
> 
> Thanks for working on this Timo, I am actively reviewing this change
> and thinking about alternatives.

Thanks, I did notice one problems in further testing.

The symptom is that once learned pmtu expires, it is not refreshed by
fragments. This seems to be a dst caching issue. Fundamentally it seems
to be same problem that commit 05ab86c5 (xfrm4: Invalidate all ipv4
routes on IPsec pmtu events) tried to fix by flushing everything.

This some problem now happens with ip_gre bound inner flows as the pmtu
is locally generated and not received from internet to the esp/ah
packets. I believe the flush all approach is not necessary and we can
do better.

I basically have new patch set pending testing. I'll post the new patch
set sometime in next few days.