[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <eb6d0724-92d6-3c3f-b698-9734adc7e1b9@arista.com>
Date: Mon, 15 May 2023 17:25:55 +0100
From: Dmitry Safonov <dima@...sta.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: linux-kernel@...r.kernel.org, David Ahern <dsahern@...nel.org>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Jakub Kicinski <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
Andy Lutomirski <luto@...capital.net>, Ard Biesheuvel <ardb@...nel.org>,
Bob Gilligan <gilligan@...sta.com>, Dan Carpenter <error27@...il.com>,
David Laight <David.Laight@...lab.com>, Dmitry Safonov
<0x7f454c46@...il.com>, Eric Biggers <ebiggers@...nel.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Francesco Ruggeri <fruggeri05@...il.com>,
Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
Ivan Delalande <colona@...sta.com>, Leonard Crestez <cdleonard@...il.com>,
Salam Noureddine <noureddine@...sta.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v6 01/21] net/tcp: Prepare tcp_md5sig_pool for TCP-AO
On 5/15/23 05:48, Herbert Xu wrote:
> On Fri, May 12, 2023 at 09:22:51PM +0100, Dmitry Safonov wrote:
>> TCP-AO, similarly to TCP-MD5, needs to allocate tfms on a slow-path,
>> which is setsockopt() and use crypto ahash requests on fast paths,
>> which are RX/TX softirqs. Also, it needs a temporary/scratch buffer
>> for preparing the hash.
>>
>> Rework tcp_md5sig_pool in order to support other hashing algorithms
>> than MD5. It will make it possible to share pre-allocated crypto_ahash
>> descriptors and scratch area between all TCP hash users.
>>
>> Internally tcp_sigpool preferences crypto_clone_ahash() API over
>> pre-allocating per-CPU crypto requests. Kudos to Herbert, who provided
>> this new crypto API [1]. Currently, there's still per-CPU crypto request
>> allocation fallback, that is needed for ciphers, that yet don't support
>> cloning (TCP-AO requires cmac(aes128) in RFC5925).
>>
>> I was a little concerned over GFP_ATOMIC allocations of ahash and
>> crypto_request in RX/TX (see tcp_sigpool_start()), so I benchmarked both
>> "backends" with different algorithms, using patched version of iperf3[2].
>> On my laptop with i7-7600U @ 2.80GHz:
>>
>> clone-tfm per-CPU-requests
>> TCP-MD5 2.25 Gbits/sec 2.30 Gbits/sec
>> TCP-AO(hmac(sha1)) 2.53 Gbits/sec 2.54 Gbits/sec
>> TCP-AO(hmac(sha512)) 1.67 Gbits/sec 1.64 Gbits/sec
>> TCP-AO(hmac(sha384)) 1.77 Gbits/sec 1.80 Gbits/sec
>> TCP-AO(hmac(sha224)) 1.29 Gbits/sec 1.30 Gbits/sec
>> TCP-AO(hmac(sha3-512)) 481 Mbits/sec 480 Mbits/sec
>> TCP-AO(hmac(md5)) 2.07 Gbits/sec 2.12 Gbits/sec
>> TCP-AO(hmac(rmd160)) 1.01 Gbits/sec 995 Mbits/sec
>> TCP-AO(cmac(aes128)) [not supporetd yet] 2.11 Gbits/sec
>>
>> So, it seems that my concerns don't have strong grounds and per-CPU
>> crypto_request allocation can be dropped/removed from tcp_sigpool once
>> ciphers get crypto_clone_ahash() support.
>
> This support is now in the upstream kernel. Please let me know
> if you run into any issues using it.
Hi Herbert, thanks for your patches. Could you point me to the repo that
has ciphers clone-tfm support? I've looked in Torvald's/master, your
cryptodev-2.6.git and in linux-next, but I can't see anywhere in
cmac_create() something of inst->alg.base.clone_tfm = cmac_clone_tfm kind.
As I wrote two paragraphs above, it's required for TCP-AO to provide
cmac(aes128) support. Let me know if you have cmac clone-tfm somewhere
or if you're cooking it. On the cover-letter for this patch set, it's in
TODO.
Thanks,
Dmitry
Powered by blists - more mailing lists