[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZOxsAR42r8t3z0Dq@hog>
Date: Mon, 28 Aug 2023 11:42:25 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Scott Dial <scott@...ttdial.com>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next] macsec: introduce default_async_crypto sysctl
2023-08-24, 13:08:41 -0400, Scott Dial wrote:
> On 8/24/2023 9:01 AM, Sabrina Dubroca wrote:
> > 2023-08-23, 16:22:31 -0400, Scott Dial wrote:
> > > AES-NI's implementation of gcm(aes) requires the FPU, so if it's busy the
> > > decrypt gets stuck on the cryptd queue, but that queue is not
> > > order-preserving.
> >
> > It should be (per CPU [*]). The queue itself is a linked list, and if we
> > have requests on the queue we don't let new requests skip the queue.
>
> My apologies, I'll be the first to admit that I have not tracked all of the
> code changes to either the macsec driver or linux-crypto since I first made
> the commit. This comment that requests are queued forced me to review the
> code again and it appears that the queueing issue was resolved in v5.2-rc1
> with commit 1661131a0479, so I no longer believe we need the
> CRYPTO_ALG_ASYNC since v5.2 and going forward.
Are you sure about this? 1661131a0479 pre-dates your patch by over a
year.
And AFAICT, that series only moved the existing FPU usable +
cryptd_aead_queued tests from AESNI's implementation of gcm(aes) to
common SIMD helpers.
--
Sabrina
Powered by blists - more mailing lists