mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>
Cc: brouer@redhat.com,
	"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
	"Larysa Zaremba" <larysa.zaremba@intel.com>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Song Liu" <song@kernel.org>,
	"Jesper Dangaard Brouer" <hawk@kernel.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 0/2] xdp: recycle Page Pool backed skbs built from XDP frames
Date: Fri, 3 Mar 2023 11:39:06 +0100	[thread overview]
Message-ID: <22ca47ca-325f-f4df-af5d-344be6b372d8@redhat.com> (raw)
In-Reply-To: <20230301160315.1022488-1-aleksander.lobakin@intel.com>


On 01/03/2023 17.03, Alexander Lobakin wrote:
> Yeah, I still remember that "Who needs cpumap nowadays" (c), but anyway.
> 
> __xdp_build_skb_from_frame() missed the moment when the networking stack
> became able to recycle skb pages backed by a Page Pool. This was making
                                                ^^^^^^^^^
When talking about page_pool, can we write "page_pool" instead of
capitalized "Page Pool", please. I looked through the git log, and here
we all used "page_pool".

> e.g. cpumap redirect even less effective than simple %XDP_PASS. veth was
> also affected in some scenarios.

Thanks for working on closing this gap :-)

> A lot of drivers use skb_mark_for_recycle() already, it's been almost
> two years and seems like there are no issues in using it in the generic
> code too. {__,}xdp_release_frame() can be then removed as it losts its
> last user.
> Page Pool becomes then zero-alloc (or almost) in the abovementioned
> cases, too. Other memory type models (who needs them at this point)
> have no changes.
> 
> Some numbers on 1 Xeon Platinum core bombed with 27 Mpps of 64-byte
> IPv6 UDP:

What NIC driver?

> 
> Plain %XDP_PASS on baseline, Page Pool driver:
> 
> src cpu Rx     drops  dst cpu Rx
>    2.1 Mpps       N/A    2.1 Mpps
> 
> cpumap redirect (w/o leaving its node) on baseline:
> 
>    6.8 Mpps  5.0 Mpps    1.8 Mpps
> 
> cpumap redirect with skb PP recycling:
> 
>    7.9 Mpps  5.7 Mpps    2.2 Mpps   +22%
> 

It is of cause awesome, that cpumap SKBs are faster than normal SKB path.
I do wonder where the +22% number comes from?

> Alexander Lobakin (2):
>    xdp: recycle Page Pool backed skbs built from XDP frames
>    xdp: remove unused {__,}xdp_release_frame()
> 
>   include/net/xdp.h | 29 -----------------------------
>   net/core/xdp.c    | 19 ++-----------------
>   2 files changed, 2 insertions(+), 46 deletions(-)
> 


  parent reply	other threads:[~2023-03-03 10:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-01 16:03 Alexander Lobakin
2023-03-01 16:03 ` [PATCH bpf-next v1 1/2] " Alexander Lobakin
2023-03-01 19:08   ` kernel test robot
2023-03-01 19:18   ` kernel test robot
2023-03-02  2:30   ` Yunsheng Lin
2023-03-03 10:31     ` Jesper Dangaard Brouer
2023-03-03 11:22     ` Alexander Lobakin
2023-03-03 12:44       ` Yunsheng Lin
2023-03-03 13:26         ` Alexander Lobakin
2023-03-06  1:09           ` Yunsheng Lin
2023-03-06 11:58             ` Alexander Lobakin
2023-03-07  2:50               ` Yunsheng Lin
2023-03-07 18:14                 ` Alexander Lobakin
2023-03-08  6:27                   ` Yunsheng Lin
2023-03-09 16:27                     ` Alexander Lobakin
2023-03-01 16:03 ` [PATCH bpf-next v1 2/2] xdp: remove unused {__,}xdp_release_frame() Alexander Lobakin
2023-03-03 10:39 ` Jesper Dangaard Brouer [this message]
2023-03-03 11:31   ` [PATCH bpf-next v1 0/2] xdp: recycle Page Pool backed skbs built from XDP frames 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=22ca47ca-325f-f4df-af5d-344be6b372d8@redhat.com \
    --to=jbrouer@redhat.com \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=hawk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=song@kernel.org \
    --cc=toke@redhat.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®