netdev.vger.kernel.org archive mirror
 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 0/5] skbuff: introduce skbuff_heads bulking and reusing
Date: Mon, 11 Jan 2021 18:27:21 +0000	[thread overview]
Message-ID: <20210111182655.12159-1-alobakin@pm.me> (raw)

Inspired by cpu_map_kthread_run() and _kfree_skb_defer() logics.

Currently, all sorts of skb allocation always do allocate
skbuff_heads one by one via kmem_cache_alloc().
On the other hand, we have percpu napi_alloc_cache to store
skbuff_heads queued up for freeing and flush them by bulks.

We can use this struct to cache and bulk not only freeing, but also
allocation of new skbuff_heads, as well as to reuse cached-to-free
heads instead of allocating the new ones.
As accessing napi_alloc_cache implies NAPI softirq context, do this
only for __napi_alloc_skb() and its derivatives (napi_alloc_skb()
and napi_get_frags()). The rough amount of their call sites are 69,
which is quite a number.

iperf3 showed a nice bump from 910 to 935 Mbits while performing
UDP VLAN NAT on 1.2 GHz MIPS board. The boost is likely to be
way bigger on more powerful hosts and NICs with tens of Mpps.

Patches 1-2 are preparation steps, while 3-5 do the real work.

Alexander Lobakin (5):
  skbuff: rename fields of struct napi_alloc_cache to be more intuitive
  skbuff: open-code __build_skb() inside __napi_alloc_skb()
  skbuff: reuse skbuff_heads from flush_skb_cache if available
  skbuff: allocate skbuff_heads by bulks instead of one by one
  skbuff: refill skb_cache early from deferred-to-consume entries

 net/core/skbuff.c | 62 ++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 48 insertions(+), 14 deletions(-)

-- 
2.30.0



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

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-11 18:27 Alexander Lobakin [this message]
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   ` [PATCH net-next 4/5] skbuff: allocate skbuff_heads by bulks instead of one by one Alexander Lobakin
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=20210111182655.12159-1-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 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).