From: Jakub Kicinski <kuba@kernel.org>
To: Yunsheng Lin <linyunsheng@huawei.com>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
<edumazet@google.com>, <pabeni@redhat.com>, <hawk@kernel.org>,
<ilias.apalodimas@linaro.org>
Subject: Re: [RFC net-next 1/2] page_pool: allow caching from safely localized NAPI
Date: Mon, 3 Apr 2023 18:45:45 -0700 [thread overview]
Message-ID: <20230403184545.3eeb6e83@kernel.org> (raw)
In-Reply-To: <1f9cf03e-94cf-9787-44ce-23f6a8dd0a7a@huawei.com>
On Tue, 4 Apr 2023 08:53:36 +0800 Yunsheng Lin wrote:
> I wonder if we can make this more generic by adding the skb to per napi
> list instead of sd->defer_list, so that we can always use NAPI kicking to
> flush skb as net_tx_action() done for sd->completion_queue instead of
> softirq kicking?
>
> And it seems we know which napi binds to a specific socket through
> busypoll mechanism, we can reuse that to release a skb to the napi
> bound to that socket?
Seems doable. My thinking was to first see how well the simpler scheme
performs with production workloads because it should have no downsides.
Tracking real NAPI pointers per socket and extra RCU sync to manage
per-NAPI defer queues may have perf cost.
next prev parent reply other threads:[~2023-04-04 1:45 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 4:39 [RFC net-next 1/2] page_pool: allow caching from safely localized NAPI Jakub Kicinski
2023-03-31 4:39 ` [RFC net-next 2/2] bnxt: hook NAPIs to page pools Jakub Kicinski
2023-03-31 5:15 ` [RFC net-next 1/2] page_pool: allow caching from safely localized NAPI Jakub Kicinski
2023-03-31 9:31 ` Jesper Dangaard Brouer
2023-03-31 19:06 ` Jakub Kicinski
2023-03-31 22:17 ` Jakub Kicinski
2023-04-03 9:16 ` Ilias Apalodimas
2023-04-03 15:05 ` Jakub Kicinski
2023-04-03 15:30 ` Ilias Apalodimas
2023-04-03 17:12 ` Jakub Kicinski
2023-04-05 17:04 ` Dragos Tatulea
2023-04-04 0:53 ` Yunsheng Lin
2023-04-04 1:45 ` Jakub Kicinski [this message]
2023-04-04 3:18 ` Yunsheng Lin
2023-04-04 4:21 ` Eric Dumazet
2023-04-04 10:50 ` Yunsheng Lin
2023-04-05 17:11 ` Eric Dumazet
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=20230403184545.3eeb6e83@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=linyunsheng@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 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).