From: Jason Wang <jasowang@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: davem@davemloft.net, mst@redhat.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu
Date: Wed, 6 Apr 2016 14:22:22 +0800 [thread overview]
Message-ID: <5704AB1E.2010100@redhat.com> (raw)
In-Reply-To: <1459515859.6473.277.camel@edumazet-glaptop3.roam.corp.google.com>
On 04/01/2016 09:04 PM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 12:49 +0800, Jason Wang wrote:
>> On 04/01/2016 10:55 AM, Eric Dumazet wrote:
>>> On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>>>
>>>
>>>> The problem is we want to support busy polling for tun. This needs
>>>> napi_id to be passed to tun socket by sk_mark_napi_id() during
>>>> tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
>>>> make us can't see correct napi_id.
>>>>
>>> Looks like napi_id should have precedence then ?
>> But then when busy polling is enabled, we may still hit the issue before
>> commit 2bd82484bb4c5db1d5dc983ac7c409b2782e0154? So looks like sometimes
>> (e.g for tun), we need both two fields.
> You did not clearly show me the path you take where both fields would be
> needed. If you expect me to do that, it wont happen.
Right, since tun does not use XPS. But the stacked device on top of tun
does not know this which may still try to set sender_cpu.
>
>>> Only forwarding should allow the field to be cleared to allow XPS to do
>>> its job.
>>>
>>> Maybe skb_sender_cpu_clear() was removed too early (commit
>>> 64d4e3431e686dc37ce388ba531c4c4e866fb141)
>> Not sure I get you, but this will clear napi_id too.
> Only when allowed. In your case it would not be called.
Looks like I miss something, there used to be a skb_sender_cpu_clear()
in br_dev_queue_push_xmit() which will be called before tun_net_xmit().
>
> Some people do not use tun, and want to forward or cook millions of
> packets per second. sk_buff size is critical.
>
> If busy polling gives you 5 % of performance improvement, but cost
> everyone else a performance decrease, this is a serious problem.
>
> XPS is a sender problem, NAPI is a receiver problem. Fields should be
> shared.
>
How about introduce a napi_id field in softnet_data to record the napi
that is being polled, then sk_mark_napi_id() can fetch napi_id from it
instead of skb?
next prev parent reply other threads:[~2016-04-06 6:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 5:50 [PATCH net-next 0/6] net device rx busy polling support in vhost_net Jason Wang
2016-03-31 5:50 ` [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu Jason Wang
2016-03-31 10:32 ` Eric Dumazet
2016-03-31 20:01 ` David Miller
2016-04-01 2:46 ` Jason Wang
2016-04-01 2:13 ` Jason Wang
2016-04-01 2:55 ` Eric Dumazet
2016-04-01 4:49 ` Jason Wang
2016-04-01 13:04 ` Eric Dumazet
2016-04-05 15:05 ` Michael S. Tsirkin
2016-04-06 6:22 ` Jason Wang [this message]
2016-03-31 5:50 ` [PATCH net-next 2/6] tuntap: socket rx busy polling support Jason Wang
2016-03-31 5:50 ` [PATCH net-next 3/6] macvtap: " Jason Wang
2016-03-31 5:50 ` [PATCH net-next 4/6] net: core: factor out core busy polling logic to sk_busy_loop_once() Jason Wang
2016-03-31 5:50 ` [PATCH net-next 5/6] net: export napi_by_id() Jason Wang
2016-03-31 5:50 ` [PATCH net-next 6/6] vhost_net: net device rx busy polling support Jason Wang
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=5704AB1E.2010100@redhat.com \
--to=jasowang@redhat.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--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).