mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexander Lobakin <alobakin@pm.me>
To: "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>,
	"Alexander Lobakin" <alobakin@pm.me>,
	"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>,
	"Paolo Abeni" <pabeni@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>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: [v3 net-next 00/10] skbuff: introduce skbuff_heads bulking and reusing
Date: Tue, 09 Feb 2021 20:46:31 +0000	[thread overview]
Message-ID: <20210209204533.327360-1-alobakin@pm.me> (raw)

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 cache not only for bulk-wiping, but also to obtain
heads for new skbs and avoid unconditional allocations, as well as
for bulk-allocating.
As accessing napi_alloc_cache implies NAPI softirq context, decaching
is protected with in_serving_softirq() check, with the option to
bypass the check when the context is 100% known.

iperf3 showed 35-70 Mbps bumps for both TCP and UDP while performing
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.

Note on skbuff_heads from distant slabs or pfmemalloc'ed slabs:
 - kmalloc()/kmem_cache_alloc() itself allows by default allocating
   memory from the remote nodes to defragment their slabs. This is
   controlled by sysctl, but according to this, skbuff_head from a
   remote node is an OK case;
 - The easiest way to check if the slab of skbuff_head is remote or
   pfmemalloc'ed is:

	if (!dev_page_is_reusable(virt_to_head_page(skb)))
		/* drop it */;

   ...*but*, regarding that most slabs are built of compound pages,
   virt_to_head_page() will hit unlikely-branch every single call.
   This check costed at least 20 Mbps in test scenarios and seems
   like it'd be better to _not_ do this.

Since v2 [1]:
 - also cover {,__}alloc_skb() and {,__}build_skb() cases (became handy
   after the changes that pass tiny skbs requests to kmalloc layer);
 - cover the cache with KASAN instrumentation (suggested by Eric
   Dumazet, help of Dmitry Vyukov);
 - completely drop redundant __kfree_skb_flush() (also Eric);
 - lots of code cleanups;
 - expand the commit message with NUMA and pfmemalloc points (Jakub).

Since v1 [0]:
 - use one unified cache instead of two separate to greatly simplify
   the logics and reduce hotpath overhead (Edward Cree);
 - new: recycle also GRO_MERGED_FREE skbs instead of immediate
   freeing;
 - correct performance numbers after optimizations and performing
   lots of tests for different use cases.

[0] https://lore.kernel.org/netdev/20210111182655.12159-1-alobakin@pm.me
[1] https://lore.kernel.org/netdev/20210113133523.39205-1-alobakin@pm.me

Alexander Lobakin (10):
  skbuff: move __alloc_skb() next to the other skb allocation functions
  skbuff: simplify kmalloc_reserve()
  skbuff: make __build_skb_around() return void
  skbuff: simplify __alloc_skb() a bit
  skbuff: use __build_skb_around() in __alloc_skb()
  skbuff: remove __kfree_skb_flush()
  skbuff: move NAPI cache declarations upper in the file
  skbuff: reuse NAPI skb cache on allocation path (__build_skb())
  skbuff: reuse NAPI skb cache on allocation path (__alloc_skb())
  skbuff: queue NAPI_MERGED_FREE skbs into NAPI cache instead of freeing

 include/linux/skbuff.h   |   4 +-
 net/core/dev.c           |  15 +-
 net/core/skbuff.c        | 392 ++++++++++++++++++++-------------------
 net/netlink/af_netlink.c |   2 +-
 4 files changed, 202 insertions(+), 211 deletions(-)

-- 
2.30.0



             reply	other threads:[~2021-02-10  0:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 20:46 Alexander Lobakin [this message]
2021-02-09 20:47 ` [v3 net-next 01/10] skbuff: move __alloc_skb() next to the other skb allocation functions Alexander Lobakin
2021-02-09 20:47 ` [v3 net-next 02/10] skbuff: simplify kmalloc_reserve() Alexander Lobakin
2021-02-09 20:47 ` [v3 net-next 03/10] skbuff: make __build_skb_around() return void Alexander Lobakin
2021-02-09 20:48 ` [v3 net-next 04/10] skbuff: simplify __alloc_skb() a bit Alexander Lobakin
2021-02-09 20:48 ` [v3 net-next 05/10] skbuff: use __build_skb_around() in __alloc_skb() Alexander Lobakin
2021-02-09 20:48 ` [v3 net-next 06/10] skbuff: remove __kfree_skb_flush() Alexander Lobakin
2021-02-09 20:48 ` [v3 net-next 07/10] skbuff: move NAPI cache declarations upper in the file Alexander Lobakin
2021-02-09 20:48 ` [v3 net-next 08/10] skbuff: reuse NAPI skb cache on allocation path (__build_skb()) Alexander Lobakin
2021-02-10 10:21   ` Paolo Abeni
2021-02-10 12:25     ` Alexander Lobakin
2021-02-10 12:51       ` Paolo Abeni
2021-02-10 17:25       ` Jesper Dangaard Brouer
2021-02-10 13:15   ` Florian Westphal
2021-02-09 20:49 ` [v3 net-next 09/10] skbuff: reuse NAPI skb cache on allocation path (__alloc_skb()) Alexander Lobakin
2021-02-09 20:49 ` [v3 net-next 10/10] 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=20210209204533.327360-1-alobakin@pm.me \
    --to=alobakin@pm.me \
    --cc=0x7f454c46@gmail.com \
    --cc=andriin@fb.com \
    --cc=ap420073@gmail.com \
    --cc=ast@kernel.org \
    --cc=bjorn@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=elver@google.com \
    --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=pabeni@redhat.com \
    --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®