lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: IPv6 PMTU/MTU related patch for 2.5.31 kernel
From
Date

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




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.026 / U:11.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site