From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, kubakici@wp.pl
Subject: Re: [PATCH net-next V2 1/3] tap: use build_skb() for small packet
Date: Wed, 16 Aug 2017 11:57:51 +0800 [thread overview]
Message-ID: <5280f66f-85cf-fa4f-1a1c-7acbac2c9ab7@redhat.com> (raw)
In-Reply-To: <20170816064951-mutt-send-email-mst@kernel.org>
On 2017年08月16日 11:55, Michael S. Tsirkin wrote:
> On Tue, Aug 15, 2017 at 08:45:20PM -0700, Eric Dumazet wrote:
>> On Fri, 2017-08-11 at 19:41 +0800, Jason Wang wrote:
>>> We use tun_alloc_skb() which calls sock_alloc_send_pskb() to allocate
>>> skb in the past. This socket based method is not suitable for high
>>> speed userspace like virtualization which usually:
>>>
>>> - ignore sk_sndbuf (INT_MAX) and expect to receive the packet as fast as
>>> possible
>>> - don't want to be block at sendmsg()
>>>
>>> To eliminate the above overheads, this patch tries to use build_skb()
>>> for small packet. We will do this only when the following conditions
>>> are all met:
>>>
>>> - TAP instead of TUN
>>> - sk_sndbuf is INT_MAX
>>> - caller don't want to be blocked
>>> - zerocopy is not used
>>> - packet size is smaller enough to use build_skb()
>>>
>>> Pktgen from guest to host shows ~11% improvement for rx pps of tap:
>>>
>>> Before: ~1.70Mpps
>>> After : ~1.88Mpps
>>>
>>> What's more important, this makes it possible to implement XDP for tap
>>> before creating skbs.
>> Well well well.
>>
>> You do realize that tun_build_skb() is not thread safe ?
> The issue is alloc frag, isn't it?
> I guess for now we can limit this to XDP mode only, and
> just allocate full pages in that mode.
>
>
Limit this to XDP mode only does not prevent user from sending packets
to same queue in parallel I think?
Thanks
next prev parent reply other threads:[~2017-08-16 3:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-11 11:41 [PATCH net-next V2 0/3] XDP support for tap Jason Wang
2017-08-11 11:41 ` [PATCH net-next V2 1/3] tap: use build_skb() for small packet Jason Wang
2017-08-16 3:45 ` Eric Dumazet
2017-08-16 3:55 ` Michael S. Tsirkin
2017-08-16 3:57 ` Jason Wang [this message]
2017-08-16 3:59 ` Michael S. Tsirkin
2017-08-16 4:07 ` Jason Wang
2017-08-16 9:17 ` Jason Wang
2017-08-16 16:30 ` David Miller
2017-08-16 3:55 ` Jason Wang
2017-08-16 10:24 ` Eric Dumazet
2017-08-16 13:16 ` Jason Wang
2017-08-11 11:41 ` [PATCH net-next V2 2/3] net: export some generic xdp helpers Jason Wang
2017-08-11 11:41 ` [PATCH net-next V2 3/3] tap: XDP support Jason Wang
2017-08-11 23:12 ` Jakub Kicinski
2017-08-12 2:48 ` Jason Wang
2017-08-14 16:01 ` Michael S. Tsirkin
2017-08-15 5:02 ` Jason Wang
2017-08-16 3:45 ` Michael S. Tsirkin
2017-08-14 8:43 ` Daniel Borkmann
2017-08-15 4:55 ` Jason Wang
2017-08-14 2:56 ` [PATCH net-next V2 0/3] XDP support for tap David Miller
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=5280f66f-85cf-fa4f-1a1c-7acbac2c9ab7@redhat.com \
--to=jasowang@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=kubakici@wp.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).