From: Hannes Frederic Sowa <hannes@stressinduktion•org>
To: Jesse Gross <jesse@kernel•org>, David Wragg <david@weave•works>
Cc: David Miller <davem@davemloft•net>,
dev@openvswitch•org,
Linux Kernel Network Developers <netdev@vger•kernel.org>
Subject: Re: [ovs-dev] [PATCH net 0/2] vxlan: Set a large MTU on ovs-created vxlan devices
Date: Thu, 7 Jan 2016 01:14:38 +0100 [thread overview]
Message-ID: <568DADEE.1050206@stressinduktion.org> (raw)
In-Reply-To: <CAEh+42iWSZOyikNydU2Bs8meqYfrKfUJLDGFJ8HzQ06k64LP0g@mail.gmail.com>
Hi,
On 07.01.2016 00:57, Jesse Gross wrote:
> On Wed, Jan 6, 2016 at 3:25 PM, David Wragg <david@weave•works> wrote:
>> David Miller <davem@davemloft•net> writes:
>>>> Prior to 4.3, openvswitch 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.
>>>>
>>>> These two patches set the MTU on openvswitch-crated vxlan devices to
>>>> be 65465 (the maximum IP packet size minus the vxlan-on-IPv6
>>>> overhead), effectively restoring the behaviour prior to 4.3. In order
>>>> to accomplish this, the first patch removes the MTU constraint of 1500
>>>> for vxlan netdevs without an underlying device.
>>>
>>> Is this really the right thing to do?
>>
>> I'm certainly open to suggestions of better ways to solve the problem.
>
> One option is to simply set the MTU on the device from userspace.
>
> The reality is that the code you're modifying is compatibility code.
> Maybe we should make this change to preserve the old behavior for old
> callers (although, again, it should not be just for VXLAN). But no new
> features or tunnel types will be supported in this manner.
>
> New or updated userspace programs should work by simply creating and
> adding tunnel devices to OVS. That won't go through this path at all
> so you're going to need to find another approach in the near future in
> any case.
I don't see any other way as to make MTUs part of the flow if we want to
have correct ip_local_error notifications. And those must also work
across VMs, so openvswitch in quasi brouting mode would need to emit
ICMP PtBs (hopefully with a correct source address, otherwise uRPF kills
them before reaching the applications) or do error signaling via virtio_net.
Either the openvswitch user space can feed those information to the
datapath or the ovs dataplane can do a lookup on the outer ip address
while filling out the metadata_dst and caching it in the flow or we just
keep the dst in the flow anyway. So a net_device used by ovs has no real
mtu anymore.
Bye,
Hannes
next prev parent reply other threads:[~2016-01-07 0:14 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
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
[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 [this message]
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
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=568DADEE.1050206@stressinduktion.org \
--to=hannes@stressinduktion$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=david@weave$(echo .)works \
--cc=dev@openvswitch$(echo .)org \
--cc=jesse@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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