All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: "Björn Töpel" <bjorn.topel@gmail.com>
Cc: Netdev <netdev@vger.kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Björn Töpel" <bjorn.topel@intel.com>, bpf <bpf@vger.kernel.org>,
	"Magnus Karlsson" <magnus.karlsson@gmail.com>,
	"Karlsson, Magnus" <magnus.karlsson@intel.com>,
	"Samudrala, Sridhar" <sridhar.samudrala@intel.com>
Subject: Re: [PATCH bpf-next v2] libbpf: use implicit XSKMAP lookup from AF_XDP XDP program
Date: Mon, 21 Oct 2019 14:19:45 +0200	[thread overview]
Message-ID: <87bluaqoim.fsf@toke.dk> (raw)
In-Reply-To: <CAJ+HfNiNwTbER1NfaKamx0p1VcBHjHSXb4_66+2eBff95pmNFg@mail.gmail.com>

Björn Töpel <bjorn.topel@gmail.com> writes:

> On Mon, 21 Oct 2019 at 13:50, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Björn Töpel <bjorn.topel@gmail.com> writes:
>>
>> > From: Björn Töpel <bjorn.topel@intel.com>
>> >
>> > In commit 43e74c0267a3 ("bpf_xdp_redirect_map: Perform map lookup in
>> > eBPF helper") the bpf_redirect_map() helper learned to do map lookup,
>> > which means that the explicit lookup in the XDP program for AF_XDP is
>> > not needed for post-5.3 kernels.
>> >
>> > This commit adds the implicit map lookup with default action, which
>> > improves the performance for the "rx_drop" [1] scenario with ~4%.
>> >
>> > For pre-5.3 kernels, the bpf_redirect_map() returns XDP_ABORTED, and a
>> > fallback path for backward compatibility is entered, where explicit
>> > lookup is still performed. This means a slight regression for older
>> > kernels (an additional bpf_redirect_map() call), but I consider that a
>> > fair punishment for users not upgrading their kernels. ;-)
>> >
>> > v1->v2: Backward compatibility (Toke) [2]
>> >
>> > [1] # xdpsock -i eth0 -z -r
>> > [2] https://lore.kernel.org/bpf/87pnirb3dc.fsf@toke.dk/
>> >
>> > Suggested-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
>> > ---
>> >  tools/lib/bpf/xsk.c | 45 +++++++++++++++++++++++++++++++++++----------
>> >  1 file changed, 35 insertions(+), 10 deletions(-)
>> >
>> > diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
>> > index b0f532544c91..391a126b3fd8 100644
>> > --- a/tools/lib/bpf/xsk.c
>> > +++ b/tools/lib/bpf/xsk.c
>> > @@ -274,33 +274,58 @@ static int xsk_load_xdp_prog(struct xsk_socket *xsk)
>> >       /* This is the C-program:
>> >        * SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx)
>> >        * {
>> > -      *     int index = ctx->rx_queue_index;
>> > +      *     int ret, index = ctx->rx_queue_index;
>> >        *
>> >        *     // A set entry here means that the correspnding queue_id
>> >        *     // has an active AF_XDP socket bound to it.
>> > +      *     ret = bpf_redirect_map(&xsks_map, index, XDP_PASS);
>> > +      *     ret &= XDP_PASS | XDP_REDIRECT;
>>
>> Why the masking? Looks a bit weird (XDP return codes are not defined as
>> bitmask values), and it's not really needed, is it?
>>
>
> bpf_redirect_map() returns a 32-bit signed int, so the upper 32-bit
> will need to be cleared. Having an explicit AND is one instruction
> less than two shifts. So, it's an optimization (every instruction is
> sacred).

OIC. Well, a comment explaining that might be nice (since you're doing
per-instruction comments anyway)? :)

-Toke


  reply	other threads:[~2019-10-21 12:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-21 10:59 [PATCH bpf-next v2] libbpf: use implicit XSKMAP lookup from AF_XDP XDP program Björn Töpel
2019-10-21 11:50 ` Toke Høiland-Jørgensen
2019-10-21 12:02   ` Björn Töpel
2019-10-21 12:19     ` Toke Høiland-Jørgensen [this message]
2019-10-21 13:37       ` Björn Töpel
2019-10-21 14:35         ` Björn Töpel
2019-10-21 15:43           ` Toke Høiland-Jørgensen
2019-10-22  7:16             ` Björn Töpel

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=87bluaqoim.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=ast@kernel.org \
    --cc=bjorn.topel@gmail.com \
    --cc=bjorn.topel@intel.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=magnus.karlsson@gmail.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=sridhar.samudrala@intel.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.