netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Daniel Borkmann <daniel@iogearbox.net>, ast@fb.com
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
	David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH bpf-next] bpf_fib_lookup: return target ifindex even if neighbour lookup fails
Date: Thu, 08 Oct 2020 22:59:17 +0200	[thread overview]
Message-ID: <87a6wwe8nu.fsf@toke.dk> (raw)
In-Reply-To: <bf190e76-b178-d915-8d0d-811905d38fd2@iogearbox.net>

Daniel Borkmann <daniel@iogearbox.net> 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 <dsahern@gmail.com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
>
> 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? :)

-Toke


  reply	other threads:[~2020-10-08 20:59 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 [this message]
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
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=87a6wwe8nu.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 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).