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@xxxxxxxxx> > --- > 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
