From: John Fastabend <john.fastabend@gmail.com>
To: Louis DeLosSantos <louis.delos.devel@gmail.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
Stanislav Fomichev <sdf@google.com>,
razor@blackwall.org,
Louis DeLosSantos <louis.delos.devel@gmail.com>
Subject: RE: [PATCH 1/2] bpf: add table ID to bpf_fib_lookup BPF helper
Date: Thu, 25 May 2023 23:48:12 -0700 [thread overview]
Message-ID: <6470562cac756_2023020893@john.notmuch> (raw)
In-Reply-To: <20230505-bpf-add-tbid-fib-lookup-v1-1-fd99f7162e76@gmail.com>
Louis DeLosSantos wrote:
> Add ability to specify routing table ID to the `bpf_fib_lookup` BPF
> helper.
>
> A new field `tbid` is added to `struct bpf_fib_lookup` used as
> parameters to the `bpf_fib_lookup` BPF helper.
>
> When the helper is called with the `BPF_FIB_LOOKUP_DIRECT` flag and the
> `tbid` field in `struct bpf_fib_lookup` is greater then 0, the `tbid`
> field will be used as the table ID for the fib lookup.
>
> If the `tbid` does not exist the fib lookup will fail with
> `BPF_FIB_LKUP_RET_NOT_FWDED`.
>
> The `tbid` field becomes a union over the vlan related output fields in
> `struct bpf_fib_lookup` and will be zeroed immediately after usage.
>
> This functionality is useful in containerized environments.
>
> For instance, if a CNI wants to dictate the next-hop for traffic leaving
> a container it can create a container-specific routing table and perform
> a fib lookup against this table in a "host-net-namespace-side" TC program.
>
> This functionality also allows `ip rule` like functionality at the TC
> layer, allowing an eBPF program to pick a routing table based on some
> aspect of the sk_buff.
>
> As a concrete use case, this feature will be used in Cilium's SRv6 L3VPN
> datapath.
>
> When egress traffic leaves a Pod an eBPF program attached by Cilium will
> determine which VRF the egress traffic should target, and then perform a
> FIB lookup in a specific table representing this VRF's FIB.
>
> Signed-off-by: Louis DeLosSantos <louis.delos.devel@gmail.com>
> ---
> include/uapi/linux/bpf.h | 17 ++++++++++++++---
> net/core/filter.c | 12 ++++++++++++
> tools/include/uapi/linux/bpf.h | 17 ++++++++++++++---
> 3 files changed, 40 insertions(+), 6 deletions(-)
>
Looks good one question. Should we hide tbid behind a flag we have
lots of room. Is there any concern a user could feed a bpf_fib_lookup
into the helper without clearing the vlan fields? Perhaps by
pulling the struct from a map or something where it had been
previously used.
Thanks,
John
next prev parent reply other threads:[~2023-05-26 6:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 14:27 [PATCH 0/2] bpf: utilize table ID in bpf_fib_lookup helper Louis DeLosSantos
2023-05-25 14:27 ` [PATCH 1/2] bpf: add table ID to bpf_fib_lookup BPF helper Louis DeLosSantos
2023-05-26 6:01 ` Yonghong Song
2023-05-26 14:11 ` Louis DeLosSantos
2023-05-26 6:48 ` John Fastabend [this message]
2023-05-26 14:07 ` Louis DeLosSantos
2023-05-26 16:58 ` Yonghong Song
2023-05-25 14:28 ` [PATCH 2/2] bpf: test table ID fib lookup " Louis DeLosSantos
2023-05-26 6:02 ` Yonghong Song
2023-05-26 14:23 ` Louis DeLosSantos
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=6470562cac756_2023020893@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=louis.delos.devel@gmail.com \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=razor@blackwall.org \
--cc=sdf@google.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.