Andi, I think it needs to be RFC conformance for PMTU to avoid unnecessary probing PMTU network traffics. For UDP and ICMP which doesn't have any reference on this kind of route, the route needs to be around for a while instead of being delete within a very short time even immediately. Thanks Shirley Ma Andi Kleen <ak@muc.de>@averell.firstfloor.org on 08/28/2002 02:44:34 AM Sent by: andi@averell.firstfloor.org To: Shirley Ma/Beaverton/IBM@IBMUS cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, LTC IPv6 Subject: Re: IPv6 PMTU/MTU related patch for 2.5.31 kernel "Shirley Ma" <xma@us.ibm.com> writes: > + /* If there is no reference to this route, this route will be > + deleted by fib6_run_gc() within 30 secs. The cached decreased > + PMTU will be gone. It's possible to be deleted before any > + other protocol using it. Then the old larger pmtu will be used, > + which against RFC1981: detect an increase MUST NOT be done > + less than 5 minutes after a Packet Too Big Messages has > + been received for the given path. > + */ > + dst_hold(&nrt->u.dst); This seems overkill and could potentially tie up quite a of dst entries for dubious purposes. This RFC requirement clearly cannot be followed in all cases, e.g. when you run out of memory for the destination cache. This is one such case too. I think only following it when there is still another reference to the dst entry (e.g. from a socket) is reasonably near the spirit of the specification. -Andi - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
