[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjSYF=qCbzO25U+7NzysW94655FdMq9OBgY+91a60hjgg@mail.gmail.com>
Date: Sun, 2 Oct 2022 15:24:57 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
Isaac Manjarres <isaacmanjarres@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Will Deacon <will@...nel.org>, Marc Zyngier <maz@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Memory Management List <linux-mm@...ck.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Saravana Kannan <saravanak@...gle.com>, kernel-team@...roid.com
Subject: Re: [PATCH 07/10] crypto: Use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGN
On Sun, Oct 2, 2022 at 3:09 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>
> Non-coherent DMA for networking is going to be fun, though.
I agree that networking is likely the main performance issue, but I
suspect 99% of the cases would come from __alloc_skb().
You might want to have help from the network drivers for the "allocate
for RX vs TX", since it ends up having very different DMA coherence
issues, as you point out.
The code actually already has a SKB_ALLOC_RX flag, but despite the
name it doesn't really mean what you'd think it means.
Similarly, that code already has magic stuff to try to be
cacheline-aligned for accesses, but it's not really for DMA coherency
reasons, just purely for performance reasons (trying to make sure that
the header accesses stay in one cacheline etc).
And to be honest, it's been years and years since I did any networking, so...
Linus
Powered by blists - more mailing lists