Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>,
	Rick Jones <rick.jones2@hp.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Glen Turner <gdt@gdt.id.au>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: UDP path MTU discovery
Date: Tue, 30 Mar 2010 08:06:08 +0200	[thread overview]
Message-ID: <1269929168.1958.94.camel@edumazet-laptop> (raw)
In-Reply-To: <20100330052044.GJ20695@one.firstfloor.org>

Le mardi 30 mars 2010 à 07:20 +0200, Andi Kleen a écrit :
> On Mon, Mar 29, 2010 at 04:38:49PM -0700, Templin, Fred L wrote:
> > > 1) 4096 bytes UDP messages... well...
> > > 2) Using regular TCP for DNS servers... well...
> > > 
> > > I believe some guys were pushing TCPCT (Cookie Transactions) for this
> > > case ( http://tools.ietf.org/html/draft-simpson-tcpct-00.html )
> > > 
> > > (That is, using an enhanced TCP for long DNS queries... but not only for
> > > DNS...)
> > 
> > IPv4 gets by this by setting DF=0 in the IP header, and
> > lets the network fragment the packet if necessary. IPv6 can
> > similarly get by this by having the sending host fragment
> > the large UDP packet into IPv6 fragments no longer than
> > 1280 bytes each.
> 
> That's true -- in theory the UDP app unwilling/unable to do proper ptmudisc 
> could set the path mtu to 1280 + header and still keep path mtu discovery off 
> and then just fragment. 
> 
> Drawback would be of course suboptimal network use with too small MTUs
> in the common case.
> 
> Right now there is no right socket option to set the path mtu. We
> have a IP_MTU option, but it only works for getting the MTU.
> That's because the PMTU is in the routing cache entry and shared
> by multiple sockets. Presumably one could add a special case
> with an MTU in the socket overriding the one in the destination entry.

We have IP_MTU_DISCOVER option with four existing values



/* IP_MTU_DISCOVER values */
#define IP_PMTUDISC_DONT                0       /* Never send DF frames */
#define IP_PMTUDISC_WANT                1       /* Use per route hints  */
#define IP_PMTUDISC_DO                  2       /* Always DF            */
#define IP_PMTUDISC_PROBE               3       /* Ignore dst pmtu      */

We might add a fifth value (or open full range) and change 

static inline int ip_skb_dst_mtu(struct sk_buff *skb)
{
        struct inet_sock *inet = skb->sk ? inet_sk(skb->sk) : NULL;

        return (inet && inet->pmtudisc == IP_PMTUDISC_PROBE) ?
               skb_dst(skb)->dev->mtu : dst_mtu(skb_dst(skb));
}

->

static inline int ip_skb_dst_mtu(struct sk_buff *skb)
{
	if (skb->sk) {
		struct inet_sock *inet = inet_sk(skb->sk);

		if (inet->pmtudisc > IP_PMTUDISC_PROBE)
			return inet->pmtudisc;
		if (inet->pmtudisc == IP_PMTUDISC_PROBE)
			return skb_dst(skb)->dev->mtu;
	}
	return dst_mtu(skb_dst(skb));
}




  reply	other threads:[~2010-03-30  6:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-26  0:02 UDP path MTU discovery Glen Turner
2010-03-26  0:53 ` Rick Jones
2010-03-26  3:26   ` David Miller
2010-03-26 17:48     ` Rick Jones
2010-03-31 23:42     ` Glen Turner
2010-03-31 23:51       ` Hagen Paul Pfeifer
2010-04-01  0:06         ` Rick Jones
2010-03-26  3:24 ` David Miller
2010-03-28  8:41   ` Andi Kleen
2010-03-31 23:57     ` Glen Turner
2010-04-01  0:57       ` Andi Kleen
2010-03-28  8:50 ` Andi Kleen
2010-03-29 17:01   ` Rick Jones
2010-03-29 20:14     ` Andi Kleen
2010-03-29 20:25       ` Rick Jones
2010-03-29 20:50       ` Edgar E. Iglesias
2010-03-29 21:01         ` Rick Jones
2010-03-29 21:29           ` Eric Dumazet
2010-03-29 23:38             ` Templin, Fred L
2010-03-30  5:20               ` Andi Kleen
2010-03-30  6:06                 ` Eric Dumazet [this message]
2010-03-30  6:16                   ` Andi Kleen
2010-03-30  6:17                   ` UDP path MTU discovery II Andi Kleen
2010-03-30  6:16                 ` UDP path MTU discovery Edgar E. Iglesias
2010-03-30  6:19                   ` Andi Kleen
2010-03-30  8:20                     ` Edgar E. Iglesias
2010-03-30 14:12                       ` Andi Kleen
2010-03-30 22:04                         ` Edgar E. Iglesias
2010-03-30 15:58                     ` Templin, Fred L
2010-03-30 16:06                       ` Andi Kleen
2010-03-31 23:43     ` Glen Turner
2010-04-01  0:55       ` Andi Kleen
2010-04-02  5:41         ` Glen Turner
2010-04-04 10:25           ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1269929168.1958.94.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=Fred.L.Templin@boeing.com \
    --cc=andi@firstfloor.org \
    --cc=edgar.iglesias@gmail.com \
    --cc=gdt@gdt.id.au \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox