linux-kernel - Re: [PATCH v6 0/3] skb_array: array based FIFO for skbs

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20160601.215112.20935437120251822.davem@davemloft.net>
Date:	Wed, 01 Jun 2016 21:51:12 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mst@...hat.com
Cc:	linux-kernel@...r.kernel.org, jasowang@...hat.com,
	eric.dumazet@...il.com, netdev@...r.kernel.org,
	rostedt@...dmis.org, brouer@...hat.com, kvm@...r.kernel.org
Subject: Re: [PATCH v6 0/3] skb_array: array based FIFO for skbs

From: "Michael S. Tsirkin" <mst@...hat.com>
Date: Wed, 1 Jun 2016 15:54:34 +0300

> This is in response to the proposal by Jason to make tun
> rx packet queue lockless using a circular buffer.
> My testing seems to show that at least for the common usecase
> in networking, which isn't lockless, circular buffer
> with indices does not perform that well, because
> each index access causes a cache line to bounce between
> CPUs, and index access causes stalls due to the dependency.
> 
> By comparison, an array of pointers where NULL means invalid
> and !NULL means valid, can be updated without messing up barriers
> at all and does not have this issue.
> 
> On the flip side, cache pressure may be caused by using large queues.
> tun has a queue of 1000 entries by default and that's 8K.
> At this point I'm not sure this can be solved efficiently.
> The correct solution might be sizing the queues appropriately.
> 
> Here's an implementation of this idea: it can be used more
> or less whenever sk_buff_head can be used, except you need
> to know the queue size in advance.
 ...

I have no fundamental issues with this piece of infrastructure, but when
it gets included I want this series to include at least one use case.

This can be an adaptation of Jason's tun rx packet queue changes, or
similar.

Thanks.