linux-kernel - Re: [PATCH RFC net-next] net: WireGuard secure network tunnel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 21 Nov 2019 13:00:26 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>
Subject: Re: [PATCH RFC net-next] net: WireGuard secure network tunnel

"Jason A. Donenfeld" <Jason@...c4.com> writes:

>> > +     MAX_QUEUED_INCOMING_HANDSHAKES = 4096, /* TODO: replace this with DQL */
>> > +     MAX_STAGED_PACKETS = 128,
>> > +     MAX_QUEUED_PACKETS = 1024 /* TODO: replace this with DQL */
>>
>> Yes, please (on the TODO) :)
>>
>> FWIW, since you're using pointer rings I think the way to do this is
>> probably to just keep the limits in place as a maximum size, and then
>> use DQL (or CoDel) to throttle enqueue to those pointer rings instead of
>> just letting them fill.
>>
>> Happy to work with you on this (as I believe I've already promised), but
>> we might as well do that after the initial version is merged...
>
> I've actually implemented this a few times, but DQL always seems too
> slow to react properly, and I haven't yet been able to figure out
> what's happening. Let's indeed work on this after the initial version
> is merged. I think this change, and several more like it, will be the
> topic of some interesting discussions. But that doesn't need to happen
> /now/ I don't think.

Agreed. Let's wait until the initial version is merged and use that as a
base to benchmark against... :)

-Toke