netdev - Re: [RFC PATCH] ptr_ring: linked list fallback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 26 Feb 2018 03:10:35 +0200
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     David Miller <davem@...emloft.net>
Cc:     linux-kernel@...r.kernel.org, john.fastabend@...il.com,
        netdev@...r.kernel.org, jasowang@...hat.com
Subject: Re: [RFC PATCH] ptr_ring: linked list fallback

On Fri, Feb 16, 2018 at 04:32:05PM -0500, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@...hat.com>
> Date: Fri, 16 Feb 2018 09:40:54 +0200
> 
> > So pointer rings work fine, but they have a problem:
> > make them too small and not enough entries fit.
> > Make them too large and you start flushing your cache
> > and running out of memory.
> > 
> > This is a new idea of mine: a ring backed by a
> > linked list. Once you run out of rin entries,
> > instead of a drop you fall back on a list with
> > a common lock.
> > 
> > Should work well for the case where the ring is typically sized
> > correctly, but will help address the fact that some user try to set e.g.
> > tx queue length to 1000000.
> > 
> > My hope this will move us closer to direction where e.g. fw codel can
> > use ptr rings without locking at all.
> > The API is still very rough, and I really need to take a hard look
> > at lock nesting.
> > 
> > Completely untested, sending for early feedback/flames.
> > 
> > Signed-off-by: Michael S. Tsirkin <mst@...hat.com>
> 
> So the idea is that if a user sets a really huge TX queue length, we allocate
> a ptr_ring which is smaller, and use the backup linked list when necessary
> to provide the requested TX queue length legitimately.
> 
> Right?

Exactly, thanks for adding this clarification.

-- 
MST