All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Lobakin <alobakin@pm.me>
To: "David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Cc: Eric Dumazet <edumazet@google.com>,
	Edward Cree <ecree@solarflare.com>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	Willem de Bruijn <willemb@google.com>,
	Miaohe Lin <linmiaohe@huawei.com>,
	Alexander Lobakin <alobakin@pm.me>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Guillaume Nault <gnault@redhat.com>,
	Yadu Kishore <kyk.segfault@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH net-next 4/5] skbuff: allocate skbuff_heads by bulks instead of one by one
Date: Mon, 11 Jan 2021 18:29:22 +0000	[thread overview]
Message-ID: <20210111182801.12609-4-alobakin@pm.me> (raw)
In-Reply-To: <20210111182801.12609-1-alobakin@pm.me>

Use the same napi_alloc_cache struct and the same approach as used
for bulk-freeing skbuff_heads to allocate them for new skbs.
The new skb_cache will store up to NAPI_SKB_CACHE_SIZE (currently
64, which equals to NAPI_POLL_WEIGHT to be capable to serve one
polling cycle) and will be refilled by bulks in case of full
depletion or after completing network softirqs.

Signed-off-by: Alexander Lobakin <alobakin@pm.me>
---
 net/core/skbuff.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 0e8c597ff6ce..57a7307689f3 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -367,6 +367,8 @@ EXPORT_SYMBOL(build_skb_around);
 
 struct napi_alloc_cache {
 	struct page_frag_cache	page;
+	u32			skb_count;
+	void			*skb_cache[NAPI_SKB_CACHE_SIZE];
 	u32			flush_skb_count;
 	void			*flush_skb_cache[NAPI_SKB_CACHE_SIZE];
 };
@@ -490,7 +492,15 @@ static struct sk_buff *__napi_decache_skb(struct napi_alloc_cache *nc)
 	if (nc->flush_skb_count)
 		return nc->flush_skb_cache[--nc->flush_skb_count];
 
-	return kmem_cache_alloc(skbuff_head_cache, GFP_ATOMIC);
+	if (unlikely(!nc->skb_count))
+		nc->skb_count = kmem_cache_alloc_bulk(skbuff_head_cache,
+						      GFP_ATOMIC,
+						      NAPI_SKB_CACHE_SIZE,
+						      nc->skb_cache);
+	if (unlikely(!nc->skb_count))
+		return NULL;
+
+	return nc->skb_cache[--nc->skb_count];
 }
 
 /**
@@ -870,6 +880,7 @@ void __consume_stateless_skb(struct sk_buff *skb)
 void __kfree_skb_flush(void)
 {
 	struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
+	u32 num;
 
 	/* flush flush_skb_cache if containing objects */
 	if (nc->flush_skb_count) {
@@ -877,6 +888,13 @@ void __kfree_skb_flush(void)
 				     nc->flush_skb_cache);
 		nc->flush_skb_count = 0;
 	}
+
+	num = NAPI_SKB_CACHE_SIZE - nc->skb_count;
+	if (num)
+		nc->skb_count += kmem_cache_alloc_bulk(skbuff_head_cache,
+						       GFP_ATOMIC, num,
+						       nc->skb_cache +
+						       nc->skb_count);
 }
 
 static inline void _kfree_skb_defer(struct sk_buff *skb)
-- 
2.30.0



  parent reply	other threads:[~2021-01-11 18:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 18:27 [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing Alexander Lobakin
2021-01-11 18:28 ` [PATCH net-next 1/5] skbuff: rename fields of struct napi_alloc_cache to be more intuitive Alexander Lobakin
2021-01-11 18:28   ` [PATCH net-next 2/5] skbuff: open-code __build_skb() inside __napi_alloc_skb() Alexander Lobakin
2021-01-11 18:29   ` [PATCH net-next 3/5] skbuff: reuse skbuff_heads from flush_skb_cache if available Alexander Lobakin
2021-01-11 18:29   ` Alexander Lobakin [this message]
2021-01-11 18:29   ` [PATCH net-next 5/5] skbuff: refill skb_cache early from deferred-to-consume entries Alexander Lobakin
2021-01-11 18:49   ` [PATCH net-next 1/5] skbuff: rename fields of struct napi_alloc_cache to be more intuitive Jonathan Lemon
2021-01-11 21:03     ` Alexander Lobakin
2021-01-12  8:20 ` [PATCH net-next 0/5] skbuff: introduce skbuff_heads bulking and reusing Eric Dumazet
2021-01-12 10:56   ` Alexander Lobakin
2021-01-12 12:32     ` Eric Dumazet
2021-01-12 18:26       ` Alexander Lobakin
2021-01-12 19:19         ` Eric Dumazet
2021-01-12  9:54 ` Edward Cree
2021-01-12 11:08   ` Alexander Lobakin
2021-01-12 12:23     ` Eric Dumazet
2021-01-13  1:02       ` Jakub Kicinski
2021-01-13  4:46         ` Eric Dumazet
2021-01-13 17:03           ` Jakub Kicinski
2021-01-13 17:15             ` Eric Dumazet
2021-01-13 18:12               ` Jakub Kicinski

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=20210111182801.12609-4-alobakin@pm.me \
    --to=alobakin@pm.me \
    --cc=davem@davemloft.net \
    --cc=ecree@solarflare.com \
    --cc=edumazet@google.com \
    --cc=gnault@redhat.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kyk.segfault@gmail.com \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willemb@google.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.