On Tue, 28 May 2013 11:45:51 +0300 (EEST)
Julian Anastasov [off-list ref] wrote:

On Tue, 28 May 2013, Timo Teräs wrote:

quoted

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 <redacted>
---
 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