[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9oXfDCGmsCJJEuaPmgj7_U4yfrBoqi0wRZrOD9SdWny_w@mail.gmail.com>
Date: Fri, 14 Feb 2020 19:37:28 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>,
Netdev <netdev@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices
On 2/14/20, Eric Dumazet <eric.dumazet@...il.com> wrote:
>
>
> On 2/14/20 10:15 AM, Jason A. Donenfeld wrote:
>> On Fri, Feb 14, 2020 at 6:56 PM Eric Dumazet <eric.dumazet@...il.com>
>> wrote:
>>> Oh dear, can you describe what do you expect of a wireguard device with
>>> mtu == 0 or mtu == 1
>>>
>>> Why simply not allowing silly configurations, instead of convoluted tests
>>> in fast path ?
>>>
>>> We are speaking of tunnels adding quite a lot of headers, so we better
>>> not try to make them
>>> work on networks with tiny mtu. Just say no to syzbot.
>>
>> The idea was that wireguard might still be useful for the persistent
>> keepalive stuff. This branch becomes very cold very fast, so I don't
>> think it makes a difference performance wise, but if you feel strongly
>> about it, I can get rid of it and set a non-zero min_mtu that's the
>> smallest thing wireguard's xmit semantics will accept. It sounds like
>> you'd prefer that?
>>
> Well, if you believe that wireguard in persistent keepalive
> has some value on its own, I guess that we will have to support this mode.
Alright.
>
> Some legacy devices can have arbitrary mtu, and this has caused headaches.
> I was hoping that for brand new devices, we could have saner limits.
>
> About setting max_mtu to ~MAX_INT, does it mean wireguard will attempt
> to send UDP datagrams bigger than 64K ? Where is the segmentation done ?
The before passings off to the udp tunnel api, we indicate that we
support ip segmentation, and then it gets handled and fragmented
deeper down. Check out socket.c. This winds up being sometimes useful
for some odd people when it's faster to encrypt longer packets on
networks with no loss. I can't say I generally recommend people go
that route, but some report benefitting from it.
>
--
Jason A. Donenfeld
Deep Space Explorer
fr: +33 6 51 90 82 66
us: +1 513 476 1200
www.jasondonenfeld.com
www.zx2c4.com
zx2c4.com/keys/AB9942E6D4A4CFC3412620A749FC7012A5DE03AE.asc
Powered by blists - more mailing lists