From: Eric Dumazet <eric.dumazet@gmail.com>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
Eric Dumazet <edumazet@google.com>
Subject: Re: [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices
Date: Fri, 14 Feb 2020 10:53:27 -0800 [thread overview]
Message-ID: <ec52e8cb-5649-9167-bb14-7e9775c6a8be@gmail.com> (raw)
In-Reply-To: <CAHmME9oXfDCGmsCJJEuaPmgj7_U4yfrBoqi0wRZrOD9SdWny_w@mail.gmail.com>
On 2/14/20 10:37 AM, Jason A. Donenfeld wrote:
> On 2/14/20, Eric Dumazet <eric.dumazet@gmail.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@gmail.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.
Okay. Speaking of socket.c, I found this wg_socket_reinit() snippet :
synchronize_rcu();
synchronize_net();
Which makes little sense. Please add a comment explaining why these two
calls are needed.
next prev parent reply other threads:[~2020-02-14 18:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-14 17:34 [PATCH v2 net 0/3] wireguard fixes for 5.6-rc2 Jason A. Donenfeld
2020-02-14 17:34 ` [PATCH v2 net 1/3] wireguard: selftests: reduce complexity and fix make races Jason A. Donenfeld
2020-02-14 17:34 ` [PATCH v2 net 2/3] wireguard: receive: reset last_under_load to zero Jason A. Donenfeld
2020-02-14 17:34 ` [PATCH v2 net 3/3] wireguard: send: account for mtu=0 devices Jason A. Donenfeld
2020-02-14 17:56 ` Eric Dumazet
2020-02-14 18:15 ` Jason A. Donenfeld
2020-02-14 18:22 ` Eric Dumazet
2020-02-14 18:37 ` Jason A. Donenfeld
2020-02-14 18:53 ` Eric Dumazet [this message]
2020-02-14 21:57 ` Jason A. Donenfeld
2020-02-14 22:30 ` Eric Dumazet
2020-02-14 22:53 ` Jason A. Donenfeld
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=ec52e8cb-5649-9167-bb14-7e9775c6a8be@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=Jason@zx2c4.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).