All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Graf <tgraf-G/eBtMaohhA@public.gmane.org>
To: David Wragg <david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH net 2/2] vxlan: Set a large MTU on ovs-created vxlan devices
Date: Thu, 7 Jan 2016 12:36:41 +0100	[thread overview]
Message-ID: <20160107113641.GI32456@pox.localdomain> (raw)
In-Reply-To: <1452087186-12926-3-git-send-email-david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>

On 01/06/16 at 01:33pm, David Wragg wrote:
> Prior to 4.3, vxlan vports could transmit vxlan packets of any size,
> constrained only by the ability to transmit the resulting UDP packets.
> 4.3 introduced vxlan netdevs corresponding to vxlan vports.  These
> netdevs have an MTU, which limits the size of a packet that can be
> successfully vxlan-encapsulated.  The default value for this MTU is
> 1500, which is awkwardly small, and leads to a conspicuous change in
> behaviour for userspace.
> 
> This sets the MTU on openvswitch-created vxlan devices to be 65465
> (the maximum IP packet size minus the vxlan-on-IPv6 overhead),
> effectively restoring the behaviour prior to 4.3.  Although the
> vxlan_config struct already had a mtu field for this,
> vxlan_dev_configure mostly ignored it; that is also addressed here.

I agree with Jesse that this is fine. The tunnel net_device is a
logical device anyway and the real MTU is not known at this point
until the underlay route has been resolved.

It is really a model we should move away from though. Unless the
endpoints negotiate a proper MTU, the underlay can't possible
cope with this correctly without major performance problems due
to fragmentation.

> @@ -2810,6 +2809,12 @@ static int vxlan_dev_configure(struct net *src_net, struct net_device *dev,
>  		needed_headroom = lowerdev->hard_header_len;
>  	}
>  
> +	if (conf->mtu) {
> +		err = __vxlan_change_mtu(dev, lowerdev, dst, conf->mtu);

OK, I see the reason for the indirection in the first patch. Never
mind.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

      parent reply	other threads:[~2016-01-07 11:36 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-06 13:33 [PATCH net 0/2] vxlan: Set a large MTU on ovs-created vxlan devices David Wragg
     [not found] ` <1452087186-12926-1-git-send-email-david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
2016-01-06 13:33   ` [PATCH net 1/2] vxlan: Relax the MTU constraint on " David Wragg
     [not found]     ` <1452087186-12926-2-git-send-email-david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
2016-01-07 11:24       ` Thomas Graf
2016-01-07 11:31         ` David Wragg
2016-01-07 11:50           ` Thomas Graf
2016-01-09 18:39       ` roopa
2016-01-10 10:28         ` [ovs-dev] " Thomas Graf
2016-01-27 16:39           ` roopa
2016-01-06 20:59   ` [PATCH net 0/2] vxlan: Set a large MTU on ovs-created " David Miller
     [not found]     ` <20160106.155950.1007160228570301281.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2016-01-06 22:53       ` Jesse Gross
2016-01-06 23:25       ` David Wragg
2016-01-06 23:57         ` [ovs-dev] " Jesse Gross
2016-01-07  0:14           ` Hannes Frederic Sowa
2016-01-07  0:46             ` Jesse Gross
2016-01-07 11:49               ` Thomas Graf
     [not found]                 ` <20160107114935.GJ32456-4EA/1caXOu0mYvmMESoHnA@public.gmane.org>
2016-01-07 16:35                   ` Jesse Gross
2016-01-07 17:21                     ` [ovs-dev] " Thomas Graf
2016-01-07 17:50                       ` Hannes Frederic Sowa
     [not found]                         ` <568EA55A.7070305-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
2016-01-07 18:40                           ` Thomas Graf
     [not found]                             ` <20160107184042.GB24672-4EA/1caXOu0mYvmMESoHnA@public.gmane.org>
2016-01-08 21:29                               ` Hannes Frederic Sowa
2016-01-10 10:49                                 ` [ovs-dev] " Thomas Graf
     [not found]           ` <CAEh+42iWSZOyikNydU2Bs8meqYfrKfUJLDGFJ8HzQ06k64LP0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-07  0:29             ` David Wragg
     [not found]               ` <86wprmp6z6.fsf-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
2016-01-07  1:10                 ` Jesse Gross
2016-01-07 21:47         ` David Miller
2016-01-07 23:42           ` David Wragg
2016-01-08  2:48             ` David Miller
2016-01-06 13:33 ` [PATCH net 2/2] " David Wragg
     [not found]   ` <1452087186-12926-3-git-send-email-david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
2016-01-07 11:36     ` Thomas Graf [this message]

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=20160107113641.GI32456@pox.localdomain \
    --to=tgraf-g/ebtmaohha@public.gmane.org \
    --cc=david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org \
    --cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.