All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>,
	Tariq Toukan <ttoukan.linux@gmail.com>,
	Daniel Borkmann <borkmann@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	bpf@vger.kernel.org
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
	Tariq Toukan <tariqt@nvidia.com>,
	gal@nvidia.com, lorenzo@kernel.org, netdev@vger.kernel.org,
	echaudro@redhat.com, andrew.gospodarek@broadcom.com
Subject: Re: [PATCH bpf-next V2] bpf/xdp: optimize bpf_xdp_pointer to avoid reading sinfo
Date: Thu, 01 Jun 2023 22:37:31 +0200	[thread overview]
Message-ID: <87bkhydilw.fsf@toke.dk> (raw)
In-Reply-To: <168563651438.3436004.17735707525651776648.stgit@firesoul>

Jesper Dangaard Brouer <brouer@redhat.com> writes:

> Currently we observed a significant performance degradation in
> samples/bpf xdp1 and xdp2, due XDP multibuffer "xdp.frags" handling,
> added in commit 772251742262 ("samples/bpf: fixup some tools to be able
> to support xdp multibuffer").
>
> This patch reduce the overhead by avoiding to read/load shared_info
> (sinfo) memory area, when XDP packet don't have any frags. This improves
> performance because sinfo is located in another cacheline.
>
> Function bpf_xdp_pointer() is used by BPF helpers bpf_xdp_load_bytes()
> and bpf_xdp_store_bytes(). As a help to reviewers, xdp_get_buff_len() can
> potentially access sinfo, but it uses xdp_buff_has_frags() flags bit check
> to avoid accessing sinfo in no-frags case.
>
> The likely/unlikely instrumentation lays out asm code such that sinfo
> access isn't interleaved with no-frags case (checked on GCC 12.2.1-4).
> The generated asm code is more compact towards the no-frags case.
>
> The BPF kfunc bpf_dynptr_slice() also use bpf_xdp_pointer(). Thus, it
> should also take effect for that.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>

Thanks for fixing this!

Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>


  parent reply	other threads:[~2023-06-01 20:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 16:21 [PATCH bpf-next V2] bpf/xdp: optimize bpf_xdp_pointer to avoid reading sinfo Jesper Dangaard Brouer
2023-06-01 20:34 ` Lorenzo Bianconi
2023-06-05 20:41   ` Alexei Starovoitov
2023-06-01 20:37 ` Toke Høiland-Jørgensen [this message]
2023-06-05 20:50 ` patchwork-bot+netdevbpf

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=87bkhydilw.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andrew.gospodarek@broadcom.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=ast@kernel.org \
    --cc=borkmann@iogearbox.net \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=echaudro@redhat.com \
    --cc=gal@nvidia.com \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=tariqt@nvidia.com \
    --cc=ttoukan.linux@gmail.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.