From: David Wragg <david@weave•works>
To: Jesse Gross <jesse@kernel•org>, Tom Herbert <tom@herbertland•com>
Cc: Linux Kernel Network Developers <netdev@vger•kernel.org>,
ovs dev <dev@openvswitch•org>, David Miller <davem@davemloft•net>,
Hannes Frederic Sowa <hannes@stressinduktion•org>,
Thomas Graf <tgraf@suug•ch>,
Roopa Prabhu <roopa@cumulusnetworks•com>
Subject: Re: [PATCH net v2 2/3] geneve: Relax MTU constraints
Date: Tue, 16 Feb 2016 12:33:42 +0000 [thread overview]
Message-ID: <86vb5o3kd5.fsf@weave.works> (raw)
In-Reply-To: <CAEh+42gyHEALCjZZGjMWTLQsPgp191c4dfZYFffOL6iV7pwYHw@mail.gmail.com> (Jesse Gross's message of "Wed, 10 Feb 2016 15:52:04 +0100")
Jesse Gross <jesse@kernel•org> writes:
> On Wed, Feb 10, 2016 at 3:21 PM, Tom Herbert <tom@herbertland•com> wrote:
>> On Wed, Feb 10, 2016 at 12:59 PM, Jesse Gross <jesse@kernel•org> wrote:
>>> On Wed, Feb 10, 2016 at 12:41 PM, David Wragg <david@weave•works> wrote:
>>>> Tom Herbert <tom@herbertland•com> writes:
>>>>> The correct thing to do is determine the maximum amount of
>>>>> encapsulation overhead that can ever be set in a packet and use for
>>>>> setting the MTU. For instance, when RCO is enable in GUE, the size of
>>>>> the option is included in tunnel->encap_hlen even though it will not
>>>>> be used in all packets (via ip_tunnel_change_mtu). If there is no way
>>>>> to determine a maximum overhead a priori from configuration, then
>>>>> maximum overhead could be assumed to be maximum possible encapsulation
>>>>> header size which for Geneve is 132 bytes IIRC.
>>>>
>>>> Ok, I'll come up with a patch to address this.
>>>
>>> I don't think that this really applies in this situation. The concerns
>>> here relate to what the MTU is actually set to but this patch affects
>>> the range of MTUs allowed to be set by the user. I don't see a reason
>>> to disallow the user from setting a precise value if they know what it
>>> should be.
>>>
>> Right, but if the user sets a bad value and packets are silently
>> dropped on the floor then that seems like a bad result that could have
>> easily been prevented.
>
> Sure, we might as well prevent the extreme edge cases that can never
> be valid. In the case of Geneve though, this would be the minimum
> header size, not the maximum, since it's possible that the user
> actually knows how big the options are that they want to use.
>
> But as I said, the practical impact is low because IP_MAX_MTU is so
> much larger than the MTU of real devices. There will always be many
> values that the MTU can be set to that result in dropped packets. This
> is true of all tunnel types.
I agree with Jesse, and if there was a debate about lifting the MTU
limit on all tunnel types to IP_MAX_MTU, I'd be for that.
But for the other tunnel types, I followed the precedent of the code
that was already there, and geneve might as well be consistent.
Patch sent to the lists.
David
next prev parent reply other threads:[~2016-02-16 12:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-09 16:47 [PATCH net v2 0/3] Set a large MTU on ovs-created tunnel devices David Wragg
2016-02-09 16:47 ` [PATCH net v2 1/3] vxlan: Relax the MTU constraints David Wragg
[not found] ` <1455036424-6403-1-git-send-email-david-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
2016-02-09 16:47 ` [PATCH net v2 2/3] geneve: Relax " David Wragg
2016-02-09 18:18 ` Sergei Shtylyov
[not found] ` <56BA2D6D.6090408-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
2016-02-09 18:22 ` David Wragg
2016-02-10 7:40 ` Tom Herbert
2016-02-10 11:41 ` David Wragg
2016-02-10 11:59 ` Jesse Gross
2016-02-10 14:21 ` Tom Herbert
[not found] ` <CALx6S36kvXJUZM8_vEmF8L3bxnRiBh98Rs0wAd-HGBJ9Yyde_Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-10 14:52 ` Jesse Gross
2016-02-16 12:33 ` David Wragg [this message]
2016-02-16 16:44 ` Tom Herbert
2016-02-18 16:54 ` David Wragg
2016-02-18 20:07 ` David Miller
[not found] ` <86bn7e2c3t.fsf-1SEAoVOfG6VEzL6FDj/jAg@public.gmane.org>
2016-02-19 2:11 ` Tom Herbert
2016-02-09 16:47 ` [PATCH net v2 3/3] vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices David Wragg
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=86vb5o3kd5.fsf@weave.works \
--to=david@weave$(echo .)works \
--cc=davem@davemloft$(echo .)net \
--cc=dev@openvswitch$(echo .)org \
--cc=hannes@stressinduktion$(echo .)org \
--cc=jesse@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=roopa@cumulusnetworks$(echo .)com \
--cc=tgraf@suug$(echo .)ch \
--cc=tom@herbertland$(echo .)com \
/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