On Fri, Jan 31, 2020 at 9:43 AM Robin Murphy wrote:
>
> On 31/01/2020 2:42 pm, Eric Dumazet wrote:
> > On Fri, Jan 31, 2020 at 4:30 AM Robin Murphy wrote:
> >>
> >> ...and when that represents ~5% of the total system RAM it is a *lot*
> >> less reasonable than even 12KB. As I said, it's great to
On Fri, Jan 31, 2020 at 4:30 AM Robin Murphy wrote:
>
> ...and when that represents ~5% of the total system RAM it is a *lot*
> less reasonable than even 12KB. As I said, it's great to make a debug
> option more efficient such that what it observes is more representative
> of the non-debug
On Thu, Jan 30, 2020 at 3:46 PM Robin Murphy wrote:
>
> Hi Eric,
>
> On 2020-01-30 7:10 pm, Eric Dumazet via iommu wrote:
> > Increasing the size of dma_entry_hash size by 327680 bytes
> > has reached some bootloaders limitations.
>
> [ That might warrant some furth
Networking drivers very often have to replace one page with
another for their RX ring buffers.
A multi-queue NIC will severly hit a contention point
in dma-debug while grabbing free_entries_lock spinlock.
Adding a one entry per-cpu cache removes the need
to grab this spinlock twice per page
Increasing the size of dma_entry_hash size by 327680 bytes
has reached some bootloaders limitations.
Simply use dynamic allocations instead, and take
this opportunity to increase the hash table to 65536
buckets. Finally my 40Gbit mlx4 NIC can sustain
line rate with CONFIG_DMA_API_DEBUG=y.
Fixes:
On Fri, Feb 2, 2018 at 10:53 AM, Christoph Hellwig wrote:
> I've got patches pending to replace all that code with
> dma_direct_alloc, which will do the right thing. They were
> submitted for 4.16, and I will resend them after -rc1.
I see, thanks Christoph !