From: Qin Chuanyu <qinchuanyu@huawei.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <jasowang@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>,
"Anthony Liguori" <anthony@codemonkey.ws>,
KVM list <kvm@vger.kernel.org>, <netdev@vger.kernel.org>,
Peter Klausler <pmk@google.com>
Subject: Re: 8% performance improved by change tap interact with kernel stack
Date: Wed, 29 Jan 2014 15:12:49 +0800 [thread overview]
Message-ID: <52E8A9F1.3000700@huawei.com> (raw)
In-Reply-To: <1390920560.28432.8.camel@edumazet-glaptop2.roam.corp.google.com>
On 2014/1/28 22:49, Eric Dumazet wrote:
> On Tue, 2014-01-28 at 16:14 +0800, Qin Chuanyu wrote:
>> according perf test result,I found that there are 5%-8% cpu cost on
>> softirq by use netif_rx_ni called in tun_get_user.
>>
>> so I changed the function which cause skb transmitted more quickly.
>> from
>> tun_get_user ->
>> netif_rx_ni(skb);
>> to
>> tun_get_user ->
>> rcu_read_lock_bh();
>> netif_receive_skb(skb);
>> rcu_read_unlock_bh();
>
> No idea why you use rcu here ?
In my first version, I forgot to add lock when called netif_receive_skb
then I met a dad spinlock when using tcpdump.
tcpdump receive skb in netif_receive_skb but also in dev_queue_xmit.
and I have notice dev_queue_xmit add rcu_read_lock_bh before
transmitting skb, and this lock avoid race between softirq and transmit
thread.
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
rcu_read_lock_bh();
Now I try to xmit skb in vhost thread, so I did the same thing.
next prev parent reply other threads:[~2014-01-29 7:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 8:14 8% performance improved by change tap interact with kernel stack Qin Chuanyu
2014-01-28 8:34 ` Michael S. Tsirkin
2014-01-28 9:14 ` Qin Chuanyu
2014-01-28 9:41 ` Michael S. Tsirkin
2014-01-28 10:19 ` Qin Chuanyu
2014-01-28 10:33 ` Michael S. Tsirkin
2014-01-28 16:58 ` Stephen Hemminger
2014-01-28 17:18 ` Michael S. Tsirkin
2014-01-29 7:41 ` Qin Chuanyu
2014-01-29 7:56 ` Michael S. Tsirkin
2014-01-28 16:56 ` Rick Jones
2014-01-28 14:49 ` Eric Dumazet
2014-01-29 7:12 ` Qin Chuanyu [this message]
2014-02-11 13:21 ` Qin Chuanyu
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=52E8A9F1.3000700@huawei.com \
--to=qinchuanyu@huawei.com \
--cc=anthony@codemonkey.ws \
--cc=eric.dumazet@gmail.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=pmk@google.com \
/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.