From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Networking <netdev@vger.kernel.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Alexei Starovoitov <ast@kernel.org>,
David Miller <davem@davemloft.net>,
Jonathan Lemon <jonathan.lemon@gmail.com>
Subject: Re: [PATCH bpf-next v5 0/3] xdp: Allow lookup into devmaps before redirect
Date: Mon, 24 Jun 2019 21:38:25 +0200 [thread overview]
Message-ID: <87y31qepu6.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4BzYFCAp7yUU80ia=C5ywDBgepeaMmVPJW8VG4gLUT=ht=A@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> On Sat, Jun 22, 2019 at 7:19 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> When using the bpf_redirect_map() helper to redirect packets from XDP, the eBPF
>> program cannot currently know whether the redirect will succeed, which makes it
>> impossible to gracefully handle errors. To properly fix this will probably
>> require deeper changes to the way TX resources are allocated, but one thing that
>> is fairly straight forward to fix is to allow lookups into devmaps, so programs
>> can at least know when a redirect is *guaranteed* to fail because there is no
>> entry in the map. Currently, programs work around this by keeping a shadow map
>> of another type which indicates whether a map index is valid.
>>
>> This series contains two changes that are complementary ways to fix this issue:
>>
>> - Moving the map lookup into the bpf_redirect_map() helper (and caching the
>> result), so the helper can return an error if no value is found in the map.
>> This includes a refactoring of the devmap and cpumap code to not care about
>> the index on enqueue.
>>
>> - Allowing regular lookups into devmaps from eBPF programs, using the read-only
>> flag to make sure they don't change the values.
>>
>> The performance impact of the series is negligible, in the sense that I cannot
>> measure it because the variance between test runs is higher than the difference
>> pre/post series.
>>
>> Changelog:
>>
>> v5:
>> - Rebase on latest bpf-next.
>> - Update documentation for bpf_redirect_map() with the new meaning of flags.
>>
>> v4:
>> - Fix a few nits from Andrii
>> - Lose the #defines in bpf.h and just compare the flags argument directly to
>> XDP_TX in bpf_xdp_redirect_map().
>>
>> v3:
>> - Adopt Jonathan's idea of using the lower two bits of the flag value as the
>> return code.
>> - Always do the lookup, and cache the result for use in xdp_do_redirect(); to
>> achieve this, refactor the devmap and cpumap code to get rid the bitmap for
>> selecting which devices to flush.
>>
>> v2:
>> - For patch 1, make it clear that the change works for any map type.
>> - For patch 2, just use the new BPF_F_RDONLY_PROG flag to make the return
>> value read-only.
>>
>> ---
>>
>> Toke Høiland-Jørgensen (3):
>> devmap/cpumap: Use flush list instead of bitmap
>> bpf_xdp_redirect_map: Perform map lookup in eBPF helper
>> devmap: Allow map lookups from eBPF
>>
>>
>> include/linux/filter.h | 1
>> include/uapi/linux/bpf.h | 7 ++-
>> kernel/bpf/cpumap.c | 106 ++++++++++++++++++++-----------------------
>> kernel/bpf/devmap.c | 113 ++++++++++++++++++++++------------------------
>> kernel/bpf/verifier.c | 7 +--
>> net/core/filter.c | 29 +++++-------
>> 6 files changed, 123 insertions(+), 140 deletions(-)
>>
>
>
> Looks like you forgot to add my Acked-by's for your patches?
Ah yes, did not carry those forward for the individual patches, my
apologies. Could you perhaps be persuaded to send a new one (I believe a
response to the cover letter acking the whole series would suffice)?
I'll make sure to add the carrying forward of acks into my workflow in
the future :)
-Toke
next prev parent reply other threads:[~2019-06-24 19:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-23 2:17 [PATCH bpf-next v5 0/3] xdp: Allow lookup into devmaps before redirect Toke Høiland-Jørgensen
2019-06-23 2:17 ` [PATCH bpf-next v5 1/3] devmap/cpumap: Use flush list instead of bitmap Toke Høiland-Jørgensen
2019-06-24 16:43 ` Jonathan Lemon
2019-06-27 22:14 ` Daniel Borkmann
2019-06-28 7:14 ` Toke Høiland-Jørgensen
2019-06-23 2:17 ` [PATCH bpf-next v5 2/3] bpf_xdp_redirect_map: Perform map lookup in eBPF helper Toke Høiland-Jørgensen
2019-06-24 16:41 ` Jonathan Lemon
2019-06-27 21:55 ` Daniel Borkmann
2019-06-28 7:17 ` Toke Høiland-Jørgensen
2019-06-28 8:12 ` Daniel Borkmann
2019-06-28 8:18 ` Toke Høiland-Jørgensen
2019-06-28 8:57 ` Toke Høiland-Jørgensen
2019-06-27 22:08 ` Daniel Borkmann
2019-06-28 7:23 ` Toke Høiland-Jørgensen
2019-06-23 2:17 ` [PATCH bpf-next v5 3/3] devmap: Allow map lookups from eBPF Toke Høiland-Jørgensen
2019-06-24 16:41 ` Jonathan Lemon
2019-06-24 16:38 ` [PATCH bpf-next v5 0/3] xdp: Allow lookup into devmaps before redirect Andrii Nakryiko
2019-06-24 19:38 ` Toke Høiland-Jørgensen [this message]
2019-06-24 20:49 ` Andrii Nakryiko
2019-06-24 21:38 ` Toke Høiland-Jørgensen
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=87y31qepu6.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=jonathan.lemon@gmail.com \
--cc=netdev@vger.kernel.org \
/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).