Daniel Borkmann <[email protected]> writes: n> On 10/8/20 10:59 PM, Toke Høiland-Jørgensen wrote: >> Daniel Borkmann <[email protected]> writes: >>> On 10/8/20 4:53 PM, Toke Høiland-Jørgensen wrote: >>>> The bpf_fib_lookup() helper performs a neighbour lookup for the destination >>>> IP and returns BPF_FIB_LKUP_NO_NEIGH if this fails, with the expectation >>>> that the BPF program will pass the packet up the stack in this case. >>>> However, with the addition of bpf_redirect_neigh() that can be used instead >>>> to perform the neighbour lookup. >>>> >>>> However, for that we still need the target ifindex, and since >>>> bpf_fib_lookup() already has that at the time it performs the neighbour >>>> lookup, there is really no reason why it can't just return it in any case. >>>> With this fix, a BPF program can do the following to perform a redirect >>>> based on the routing table that will succeed even if there is no neighbour >>>> entry: >>>> >>>> ret = bpf_fib_lookup(skb, &fib_params, sizeof(fib_params), 0); >>>> if (ret == BPF_FIB_LKUP_RET_SUCCESS) { >>>> __builtin_memcpy(eth->h_dest, fib_params.dmac, ETH_ALEN); >>>> __builtin_memcpy(eth->h_source, fib_params.smac, ETH_ALEN); >>>> >>>> return bpf_redirect(fib_params.ifindex, 0); >>>> } else if (ret == BPF_FIB_LKUP_RET_NO_NEIGH) { >>>> return bpf_redirect_neigh(fib_params.ifindex, 0); >>>> } >>>> >>>> Cc: David Ahern <[email protected]> >>>> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> >>> >>> ACK, this looks super useful! Could you also add a new flag which would skip >>> neighbor lookup in the helper while at it (follow-up would be totally fine >>> from >>> my pov since both are independent from each other)? >> >> Sure, can do. Thought about adding it straight away, but wasn't sure if >> it would be useful, since the fib lookup has already done quite a lot of >> work by then. But if you think it'd be useful, I can certainly add it. >> I'll look at this tomorrow; if you merge this before then I'll do it as >> a follow-up, and if not I'll respin with it added. OK? :) > > Sounds good to me; merge depending on David's final verdict in the other > thread > wrt commit description.
Yup, figured that'd be the case - great :) -Toke
