From: Paolo Abeni <pabeni@redhat.com>
To: Alexander Lobakin <alobakin@pm.me>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>
Cc: "Jonathan Lemon" <jonathan.lemon@gmail.com>,
"Eric Dumazet" <edumazet@google.com>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Willem de Bruijn" <willemb@google.com>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Kevin Hao" <haokexin@gmail.com>,
"Pablo Neira Ayuso" <pablo@netfilter.org>,
"Jakub Sitnicki" <jakub@cloudflare.com>,
"Marco Elver" <elver@google.com>,
"Dexuan Cui" <decui@microsoft.com>,
"Jesper Dangaard Brouer" <brouer@redhat.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andriin@fb.com>,
"Taehee Yoo" <ap420073@gmail.com>,
"Cong Wang" <xiyou.wangcong@gmail.com>,
"Björn Töpel" <bjorn@kernel.org>,
"Miaohe Lin" <linmiaohe@huawei.com>,
"Guillaume Nault" <gnault@redhat.com>,
"Yonghong Song" <yhs@fb.com>, zhudi <zhudi21@huawei.com>,
"Michal Kubecek" <mkubecek@suse.cz>,
"Marcelo Ricardo Leitner" <marcelo.leitner@gmail.com>,
"Dmitry Safonov" <0x7f454c46@gmail.com>,
"Yang Yingliang" <yangyingliang@huawei.com>,
"Florian Westphal" <fw@strlen.de>,
"Edward Cree" <ecree.xilinx@gmail.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH v4 net-next 09/11] skbuff: allow to optionally use NAPI cache from __alloc_skb()
Date: Thu, 11 Feb 2021 11:16:40 +0100 [thread overview]
Message-ID: <58147c2d36ea7b6e0284d400229cd79185c53463.camel@redhat.com> (raw)
In-Reply-To: <20210210162732.80467-10-alobakin@pm.me>
On Wed, 2021-02-10 at 16:30 +0000, Alexander Lobakin wrote:
> Reuse the old and forgotten SKB_ALLOC_NAPI to add an option to get
> an skbuff_head from the NAPI cache instead of inplace allocation
> inside __alloc_skb().
> This implies that the function is called from softirq or BH-off
> context, not for allocating a clone or from a distant node.
>
> Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> ---
> net/core/skbuff.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 9e1a8ded4acc..750fa1825b28 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -397,15 +397,20 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> struct sk_buff *skb;
> u8 *data;
> bool pfmemalloc;
> + bool clone;
>
> - cache = (flags & SKB_ALLOC_FCLONE)
> - ? skbuff_fclone_cache : skbuff_head_cache;
> + clone = !!(flags & SKB_ALLOC_FCLONE);
> + cache = clone ? skbuff_fclone_cache : skbuff_head_cache;
>
> if (sk_memalloc_socks() && (flags & SKB_ALLOC_RX))
> gfp_mask |= __GFP_MEMALLOC;
>
> /* Get the HEAD */
> - skb = kmem_cache_alloc_node(cache, gfp_mask & ~__GFP_DMA, node);
> + if (!clone && (flags & SKB_ALLOC_NAPI) &&
> + likely(node == NUMA_NO_NODE || node == numa_mem_id()))
> + skb = napi_skb_cache_get();
> + else
> + skb = kmem_cache_alloc_node(cache, gfp_mask & ~GFP_DMA, node);
> if (unlikely(!skb))
> return NULL;
> prefetchw(skb);
I hope the opt-in thing would have allowed leaving this code unchanged.
I see it's not trivial avoid touching this code path.
Still I think it would be nice if you would be able to let the device
driver use the cache without touching the above, which is also used
e.g. by the TCP xmit path, which in turn will not leverage the cache
(as it requires FCLONE skbs).
If I read correctly, the above chunk is needed to
allow __napi_alloc_skb() access the cache even for small skb
allocation. Good device drivers should not call alloc_skb() in the fast
path.
What about changing __napi_alloc_skb() to always use
the __napi_build_skb(), for both kmalloc and page backed skbs? That is,
always doing the 'data' allocation in __napi_alloc_skb() - either via
page_frag or via kmalloc() - and than call __napi_build_skb().
I think that should avoid adding more checks in __alloc_skb() and
should probably reduce the number of conditional used
by __napi_alloc_skb().
Thanks!
Paolo
next prev parent reply other threads:[~2021-02-11 10:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 16:28 [PATCH v4 net-next 00/11] skbuff: introduce skbuff_heads bulking and reusing Alexander Lobakin
2021-02-10 16:28 ` [PATCH v4 net-next 01/11] skbuff: move __alloc_skb() next to the other skb allocation functions Alexander Lobakin
2021-02-10 16:28 ` [PATCH v4 net-next 02/11] skbuff: simplify kmalloc_reserve() Alexander Lobakin
2021-02-10 16:29 ` [PATCH v4 net-next 03/11] skbuff: make __build_skb_around() return void Alexander Lobakin
2021-02-10 16:29 ` [PATCH v4 net-next 04/11] skbuff: simplify __alloc_skb() a bit Alexander Lobakin
2021-02-10 16:29 ` [PATCH v4 net-next 05/11] skbuff: use __build_skb_around() in __alloc_skb() Alexander Lobakin
2021-02-10 16:29 ` [PATCH v4 net-next 06/11] skbuff: remove __kfree_skb_flush() Alexander Lobakin
2021-02-10 16:30 ` [PATCH v4 net-next 07/11] skbuff: move NAPI cache declarations upper in the file Alexander Lobakin
2021-02-10 16:30 ` [PATCH v4 net-next 08/11] skbuff: introduce {,__}napi_build_skb() which reuses NAPI cache heads Alexander Lobakin
2021-02-11 12:54 ` Jesper Dangaard Brouer
2021-02-11 14:38 ` Alexander Lobakin
2021-02-10 16:30 ` [PATCH v4 net-next 09/11] skbuff: allow to optionally use NAPI cache from __alloc_skb() Alexander Lobakin
2021-02-11 10:16 ` Paolo Abeni [this message]
2021-02-11 14:28 ` Alexander Lobakin
2021-02-11 14:55 ` Paolo Abeni
2021-02-11 15:26 ` Alexander Lobakin
2021-02-10 16:30 ` [PATCH v4 net-next 10/11] skbuff: allow to use NAPI cache from __napi_alloc_skb() Alexander Lobakin
2021-02-10 16:31 ` [PATCH v4 net-next 11/11] skbuff: queue NAPI_MERGED_FREE skbs into NAPI cache instead of freeing Alexander Lobakin
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=58147c2d36ea7b6e0284d400229cd79185c53463.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=0x7f454c46@gmail.com \
--cc=alobakin@pm.me \
--cc=andriin@fb.com \
--cc=ap420073@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=decui@microsoft.com \
--cc=dvyukov@google.com \
--cc=ecree.xilinx@gmail.com \
--cc=edumazet@google.com \
--cc=elver@google.com \
--cc=fw@strlen.de \
--cc=gnault@redhat.com \
--cc=haokexin@gmail.com \
--cc=jakub@cloudflare.com \
--cc=jonathan.lemon@gmail.com \
--cc=kuba@kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.leitner@gmail.com \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=pablo@netfilter.org \
--cc=rdunlap@infradead.org \
--cc=willemb@google.com \
--cc=xiyou.wangcong@gmail.com \
--cc=yangyingliang@huawei.com \
--cc=yhs@fb.com \
--cc=zhudi21@huawei.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
all inboxes | Powered by JetHome®