Re: [PATCH net-next 2/3] ipv4: rate limit updating of next hop exceptions with same pmtu

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

On Tue, 28 May 2013 11:45:51 +0300 (EEST)
Julian Anastasov <ja@ssi.bg> wrote:

> On Tue, 28 May 2013, Timo Teräs wrote:
> 
> > The tunnel devices call update_pmtu for each packet sent, this
> > causes contention on the fnhe_lock. Ignore the pmtu update if pmtu
> > is not actually changed, and there is still plenty of time before
> > the entry expires.
> > 
> > Signed-off-by: Timo Teräs <timo.teras@iki.fi>
> > ---
> >  net/ipv4/route.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 561a378..a4082be 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -947,6 +947,10 @@ static void __ip_rt_update_pmtu(struct rtable
> > *rt, struct flowi4 *fl4, u32 mtu) if (mtu < ip_rt_min_pmtu)
> >  		mtu = ip_rt_min_pmtu;
> >  
> > +	if (rt->rt_pmtu == mtu &&
> > +	    time_before(jiffies, dst->expires -
> > ip_rt_mtu_expires / 2))
> > +		return;
> > +
> 
> 	Can we also add logic in this patch in
> update_or_create_fnhe, so that we avoid invalidation for cached
> routes when only pmtu expiration is updated (same pmtu), i.e.:
> 
> +	if (gw || pmtu != fnhe->fnhe_pmtu) {
> +		/* Exception created; mark the cached routes for the
> nexthop
> +		...
> +	}
> 
> 	BTW, I now see that previous patch should
> call for_each_possible_cpu for the both cases, not
> only when fnhe is created but also on update:

Why would this be needed?

The idea is that if there is no next hop exception, everyone is using
the next hop's dsts. If there is a next hop exception hashed, they will
be using those routes in the exception entry.

When the exception is created, we need to invalidate the nexthop's
routes, to force relookup of these dst's if should go to the exception.
Basically it flushes the nexthop's 'default' dst.

But if we have a valid exception, and we are just updating it. Everyone
is already using the right dst. The update_or_create_fnhe() updates all
exception's dst's that are effected. Since the set of hosts to which
that exception applies is the same, I don't see why we would need to
invalidate the nexthop's 'default' dst.

- Timo