From: Jason Wang <jasowang@redhat.com>
To: David Miller <davem@davemloft.net>, mst@redhat.com
Cc: linux-kernel@vger.kernel.org, eric.dumazet@gmail.com,
netdev@vger.kernel.org, rostedt@goodmis.org, brouer@redhat.com,
kvm@vger.kernel.org
Subject: Re: [PATCH v6 0/3] skb_array: array based FIFO for skbs
Date: Thu, 2 Jun 2016 16:13:01 +0800 [thread overview]
Message-ID: <574FEA8D.1020508@redhat.com> (raw)
In-Reply-To: <20160601.215112.20935437120251822.davem@davemloft.net>
On 2016年06月02日 12:51, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.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
prev parent reply other threads:[~2016-06-02 8:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 12:54 [PATCH v6 0/3] skb_array: array based FIFO for skbs Michael S. Tsirkin
2016-06-01 12:54 ` [PATCH v6 1/3] ptr_ring: array based FIFO for pointers Michael S. Tsirkin
2016-06-01 12:54 ` [PATCH v6 2/3] ptr_ring: ring test Michael S. Tsirkin
2016-06-01 12:54 ` [PATCH v6 3/3] skb_array: array based FIFO for skbs Michael S. Tsirkin
2016-06-02 8:17 ` Jason Wang
2016-06-02 9:27 ` Michael S. Tsirkin
2016-06-02 4:51 ` [PATCH v6 0/3] " David Miller
2016-06-02 8:13 ` Jason Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574FEA8D.1020508@redhat.com \
--to=jasowang@redhat.com \
--cc=brouer@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.