From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: David Ahern <dsahern@gmail.com>, daniel@iogearbox.net, ast@fb.com
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH bpf-next] bpf_fib_lookup: return target ifindex even if neighbour lookup fails
Date: Thu, 08 Oct 2020 22:57:47 +0200 [thread overview]
Message-ID: <87d01se8qc.fsf@toke.dk> (raw)
In-Reply-To: <da1b5e5f-edb3-4384-c748-8170f51f6f6d@gmail.com>
David Ahern <dsahern@gmail.com> writes:
> On 10/8/20 7:53 AM, 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);
>> }
>>
>
> There are a lot of assumptions in this program flow and redundant work.
> fib_lookup is generic and allows the caller to control the input
> parameters. direct_neigh does a fib lookup based on network header data
> from the skb.
>
> I am fine with the patch, but users need to be aware of the subtle details.
Yeah, I'm aware they are not equivalent; the code above was just meant
as a minimal example motivating the patch. If you think it's likely to
confuse people to have this example in the commit message, I can remove
it?
-Toke
next prev parent reply other threads:[~2020-10-08 20:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 14:53 [PATCH bpf-next] bpf_fib_lookup: return target ifindex even if neighbour lookup fails Toke Høiland-Jørgensen
2020-10-08 15:08 ` Daniel Borkmann
2020-10-08 20:59 ` Toke Høiland-Jørgensen
2020-10-08 21:02 ` Daniel Borkmann
2020-10-08 21:04 ` Toke Høiland-Jørgensen
2020-10-08 17:22 ` David Ahern
2020-10-08 20:57 ` Toke Høiland-Jørgensen [this message]
2020-10-08 21:58 ` David Ahern
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=87d01se8qc.fsf@toke.dk \
--to=toke@redhat.com \
--cc=ast@fb.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dsahern@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 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.