Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     Netdev <netdev@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        David Miller <davem@davemloft.net>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH RFC net-next] net: WireGuard secure network tunnel
In-Reply-To: <CAHmME9rmFw7xGKNMURBUSiezbsBEikOPiJxtEu=i2Quzf+JNDg@mail.gmail.com>
References: <20191120203538.199367-1-Jason@zx2c4.com> <877e3t8qv7.fsf@toke.dk> <CAHmME9rmFw7xGKNMURBUSiezbsBEikOPiJxtEu=i2Quzf+JNDg@mail.gmail.com>
Date:   Thu, 21 Nov 2019 13:00:26 +0100
Message-ID: <87lfs9782t.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

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

>> > +     MAX_QUEUED_INCOMING_HANDSHAKES =3D 4096, /* TODO: replace this w=
ith DQL */
>> > +     MAX_STAGED_PACKETS =3D 128,
>> > +     MAX_QUEUED_PACKETS =3D 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