From: Jakub Kicinski <kuba@kernel.org>
To: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
aleksander.lobakin@intel.com, netdev@vger.kernel.org,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
lorenzo.bianconi@redhat.com, bpf@vger.kernel.org,
toke@redhat.com, willemdebruijn.kernel@gmail.com,
jasowang@redhat.com, sdf@google.com
Subject: Re: [PATCH v3 net-next 2/2] xdp: add multi-buff support for xdp running in generic mode
Date: Wed, 6 Dec 2023 08:03:33 -0800 [thread overview]
Message-ID: <20231206080333.0aa23754@kernel.org> (raw)
In-Reply-To: <4b9804e2-42f0-4aed-b191-2abe24390e37@kernel.org>
On Wed, 6 Dec 2023 13:41:49 +0100 Jesper Dangaard Brouer wrote:
> BUT then I realized that PP have a weakness, which is the return/free
> path that need to take a normal spin_lock, as that can be called from
> any CPU (unlike the RX/alloc case). Thus, I fear that making multiple
> devices share a page_pool via softnet_data, increase the chance of lock
> contention when packets are "freed" returned/recycled.
I was thinking we can add a pcpu CPU ID to page pool so that
napi_pp_put_page() has a chance to realize that its on the "right CPU"
and feed the cache directly.
next prev parent reply other threads:[~2023-12-06 16:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 13:48 [PATCH v3 net-next 0/2] add multi-buff support for xdp running in generic mode Lorenzo Bianconi
2023-12-01 13:48 ` [PATCH v3 net-next 1/2] xdp: rely on skb pointer reference in do_xdp_generic and netif_receive_generic_xdp Lorenzo Bianconi
2023-12-01 13:48 ` [PATCH v3 net-next 2/2] xdp: add multi-buff support for xdp running in generic mode Lorenzo Bianconi
2023-12-02 3:48 ` Jakub Kicinski
2023-12-04 15:43 ` Lorenzo Bianconi
2023-12-04 20:01 ` Jakub Kicinski
2023-12-05 23:08 ` Lorenzo Bianconi
2023-12-05 23:58 ` Jakub Kicinski
2023-12-06 12:41 ` Jesper Dangaard Brouer
2023-12-06 13:51 ` Lorenzo Bianconi
2023-12-06 16:03 ` Jakub Kicinski [this message]
2023-12-09 19:23 ` Lorenzo Bianconi
2023-12-11 17:00 ` Jakub Kicinski
2023-12-12 8:36 ` Paolo Abeni
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=20231206080333.0aa23754@kernel.org \
--to=kuba@kernel.org \
--cc=aleksander.lobakin@intel.com \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=jasowang@redhat.com \
--cc=lorenzo.bianconi@redhat.com \
--cc=lorenzo@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@google.com \
--cc=toke@redhat.com \
--cc=willemdebruijn.kernel@gmail.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.