netdev - 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: <574FEA8D.1020508@redhat.com>
Date:	Thu, 2 Jun 2016 16:13:01 +0800
From:	Jason Wang <jasowang@...hat.com>
To:	David Miller <davem@...emloft.net>, mst@...hat.com
Cc:	linux-kernel@...r.kernel.org, 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



On 2016年06月02日 12:51, David Miller wrote:
> 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.

Right, I'm working on using skb array for tun, will post the patch in 
the following days.

Thanks