netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Lobakin <alobakin@pm.me>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: "Alexander Lobakin" <alobakin@pm.me>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"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>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Jesper Dangaard Brouer" <brouer@redhat.com>,
	"Alexander Duyck" <alexanderduyck@fb.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>,
	LKML <linux-kernel@vger.kernel.org>,
	Netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH v5 net-next 06/11] skbuff: remove __kfree_skb_flush()
Date: Sat, 13 Feb 2021 13:56:40 +0000	[thread overview]
Message-ID: <20210213135604.86581-1-alobakin@pm.me> (raw)
In-Reply-To: <CAKgT0Uc=_VereGioEPrvfT8-eL6odvs9PwNxywu4=UC1DPvRNQ@mail.gmail.com>

From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Thu, 11 Feb 2021 19:28:52 -0800

> On Thu, Feb 11, 2021 at 10:57 AM Alexander Lobakin <alobakin@pm.me> wrote:
> >
> > This function isn't much needed as NAPI skb queue gets bulk-freed
> > anyway when there's no more room, and even may reduce the efficiency
> > of bulk operations.
> > It will be even less needed after reusing skb cache on allocation path,
> > so remove it and this way lighten network softirqs a bit.
> >
> > Suggested-by: Eric Dumazet <edumazet@google.com>
> > Signed-off-by: Alexander Lobakin <alobakin@pm.me>
> 
> I'm wondering if you have any actual gains to show from this patch?
> 
> The reason why I ask is because the flushing was happening at the end
> of the softirq before the system basically gave control back over to
> something else. As such there is a good chance for the memory to be
> dropped from the cache by the time we come back to it. So it may be
> just as expensive if not more so than accessing memory that was just
> freed elsewhere and placed in the slab cache.

Just retested after readding this function (and changing the logics so
it would drop the second half of the cache, like napi_skb_cache_put()
does) and got 10 Mbps drawback with napi_build_skb() +
napi_gro_receive().

So seems like getting a pointer from an array instead of calling
kmem_cache_alloc() is cheaper even if the given object was pulled
out of CPU caches.

> > ---
> >  include/linux/skbuff.h |  1 -
> >  net/core/dev.c         |  7 +------
> >  net/core/skbuff.c      | 12 ------------
> >  3 files changed, 1 insertion(+), 19 deletions(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 0a4e91a2f873..0e0707296098 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -2919,7 +2919,6 @@ static inline struct sk_buff *napi_alloc_skb(struct napi_struct *napi,
> >  }
> >  void napi_consume_skb(struct sk_buff *skb, int budget);
> >
> > -void __kfree_skb_flush(void);
> >  void __kfree_skb_defer(struct sk_buff *skb);
> >
> >  /**
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 321d41a110e7..4154d4683bb9 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -4944,8 +4944,6 @@ static __latent_entropy void net_tx_action(struct softirq_action *h)
> >                         else
> >                                 __kfree_skb_defer(skb);
> >                 }
> > -
> > -               __kfree_skb_flush();
> >         }
> >
> >         if (sd->output_queue) {
> > @@ -7012,7 +7010,6 @@ static int napi_threaded_poll(void *data)
> >                         __napi_poll(napi, &repoll);
> >                         netpoll_poll_unlock(have);
> >
> > -                       __kfree_skb_flush();
> >                         local_bh_enable();
> >
> >                         if (!repoll)
> 
> So it looks like this is the one exception to my comment above. Here
> we should probably be adding a "if (!repoll)" before calling
> __kfree_skb_flush().
> 
> > @@ -7042,7 +7039,7 @@ static __latent_entropy void net_rx_action(struct softirq_action *h)
> >
> >                 if (list_empty(&list)) {
> >                         if (!sd_has_rps_ipi_waiting(sd) && list_empty(&repoll))
> > -                               goto out;
> > +                               return;
> >                         break;
> >                 }
> >
> > @@ -7069,8 +7066,6 @@ static __latent_entropy void net_rx_action(struct softirq_action *h)
> >                 __raise_softirq_irqoff(NET_RX_SOFTIRQ);
> >
> >         net_rps_action_and_irq_enable(sd);
> > -out:
> > -       __kfree_skb_flush();
> >  }
> >
> >  struct netdev_adjacent {
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 1c6f6ef70339..4be2bb969535 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -838,18 +838,6 @@ void __consume_stateless_skb(struct sk_buff *skb)
> >         kfree_skbmem(skb);
> >  }
> >
> > -void __kfree_skb_flush(void)
> > -{
> > -       struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
> > -
> > -       /* flush skb_cache if containing objects */
> > -       if (nc->skb_count) {
> > -               kmem_cache_free_bulk(skbuff_head_cache, nc->skb_count,
> > -                                    nc->skb_cache);
> > -               nc->skb_count = 0;
> > -       }
> > -}
> > -
> >  static inline void _kfree_skb_defer(struct sk_buff *skb)
> >  {
> >         struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
> > --
> > 2.30.1

Al


  reply	other threads:[~2021-02-13 13:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 18:52 [PATCH v5 net-next 00/11] skbuff: introduce skbuff_heads bulking and reusing Alexander Lobakin
2021-02-11 18:52 ` [PATCH v5 net-next 01/11] skbuff: move __alloc_skb() next to the other skb allocation functions Alexander Lobakin
2021-02-11 18:53 ` [PATCH v5 net-next 02/11] skbuff: simplify kmalloc_reserve() Alexander Lobakin
2021-02-11 18:53 ` [PATCH v5 net-next 03/11] skbuff: make __build_skb_around() return void Alexander Lobakin
2021-02-11 18:53 ` [PATCH v5 net-next 04/11] skbuff: simplify __alloc_skb() a bit Alexander Lobakin
2021-02-11 18:53 ` [PATCH v5 net-next 05/11] skbuff: use __build_skb_around() in __alloc_skb() Alexander Lobakin
2021-02-11 18:54 ` [PATCH v5 net-next 06/11] skbuff: remove __kfree_skb_flush() Alexander Lobakin
2021-02-12  3:28   ` Alexander Duyck
2021-02-13 13:56     ` Alexander Lobakin [this message]
2021-02-11 18:54 ` [PATCH v5 net-next 07/11] skbuff: move NAPI cache declarations upper in the file Alexander Lobakin
2021-02-11 18:54 ` [PATCH v5 net-next 08/11] skbuff: introduce {,__}napi_build_skb() which reuses NAPI cache heads Alexander Lobakin
2021-02-11 18:54 ` [PATCH v5 net-next 09/11] skbuff: allow to optionally use NAPI cache from __alloc_skb() Alexander Lobakin
2021-02-12  3:18   ` Alexander Duyck
2021-02-13 11:53     ` Alexander Lobakin
2021-02-11 18:55 ` [PATCH v5 net-next 10/11] skbuff: allow to use NAPI cache from __napi_alloc_skb() Alexander Lobakin
2021-02-11 18:55 ` [PATCH v5 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=20210213135604.86581-1-alobakin@pm.me \
    --to=alobakin@pm.me \
    --cc=0x7f454c46@gmail.com \
    --cc=alexander.duyck@gmail.com \
    --cc=alexanderduyck@fb.com \
    --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=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;
as well as URLs for NNTP newsgroup(s).