All of lore.kernel.org
 help / color / mirror / Atom feed
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,
	David Ahern <dsahern@gmail.com>
Subject: Re: [PATCH bpf-next v2] bpf_fib_lookup: optionally skip neighbour lookup
Date: Fri, 09 Oct 2020 20:42:10 +0200	[thread overview]
Message-ID: <87v9fjckcd.fsf@toke.dk> (raw)
In-Reply-To: <0a463800-a663-3fd3-2e1a-eac5526ed691@gmail.com>

David Ahern <dsahern@gmail.com> writes:

> On 10/9/20 3:13 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, at the cost of a bit of duplicated work.
>> 
>> 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. So let's just
>> always return the ifindex, and also add a flag that lets the caller turn
>> off the neighbour lookup entirely in bpf_fib_lookup().
>
> seems really odd to do the fib lookup only to skip the neighbor lookup
> and defer to a second helper to do a second fib lookup and send out.
>
> The better back-to-back calls is to return the ifindex and gateway on
> successful fib lookup regardless of valid neighbor. If the call to
> bpf_redirect_neigh is needed, it can have a flag to skip the fib lookup
> and just redirect to the given nexthop address + ifindex. ie.,
> bpf_redirect_neigh only does neighbor handling in this case.

Hmm, yeah, I guess it would make sense to cache and reuse the lookup -
maybe stick it in bpf_redirect_info()? However, given the imminent
opening of the merge window, I don't see this landing before then. So
I'm going to respin this patch with just the original change to always
return the ifindex, then we can revisit the flags/reuse of the fib
lookup later.

-Toke


  reply	other threads:[~2020-10-09 18:42 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 10:13 [PATCH bpf-next v2] bpf_fib_lookup: optionally skip neighbour lookup Toke Høiland-Jørgensen
2020-10-09 16:17 ` David Ahern
2020-10-09 18:42   ` Toke Høiland-Jørgensen [this message]
2020-10-09 21:28     ` David Ahern
2020-10-09 23:05       ` Daniel Borkmann
2020-10-10 13:42         ` Toke Høiland-Jørgensen
2020-10-11 20:04           ` Daniel Borkmann

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=87v9fjckcd.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.