public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Ido Schimmel <idosch@nvidia.com>
To: netdev@vger.kernel.org, bpf@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, dsahern@gmail.com, petrm@nvidia.com,
	horms@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	andrii@kernel.org, martin.lau@linux.dev,
	john.fastabend@gmail.com, sdf@fomichev.me,
	Ido Schimmel <idosch@nvidia.com>
Subject: [RFC PATCH bpf-next 0/9] bpf: fib_lookup: IPv6 output routes enhancements
Date: Thu, 26 Feb 2026 09:59:54 +0200	[thread overview]
Message-ID: <20260226080003.524935-1-idosch@nvidia.com> (raw)

This patchset performs two changes in the bpf_fib_lookup() helper:

1. Patch #6: Aligns IPv6 with IPv4 with regards to output route lookups
(i.e., BPF_FIB_LOOKUP_OUTPUT) so that it always resolves a route whose
nexthop device matches the specified oif.

2. Patch #8: Allows output route lookups for IPv6 link-local addresses.

The rest of the patches perform small changes in the existing
bpf_fib_lookup() selftest (patches #1-#4) and add tests for the new
functionality (patches #5, #7 and #9).

I believe the patches stand on their own, but below is the motivating
use case:

We are researching the possibility of offloading the data plane of the
Bidirectional Forwarding Detection (BFD) protocol [1][2][3] from user
space (i.e., FRR) to the kernel using BPF. FRR already supports the
delegation of the data plane logic to a different daemon via the
"Distributed BFD" protocol [4].

When used in asynchronous mode, the per-session Tx logic of the protocol
boils down to periodically sending a packet to the BFD peer according to
the negotiated Tx interval. The simplified diagram below explains how
this can be implemented in the kernel using BPF:

         bpf_redirect()
     +--------------------+
     |                    |
     |                    ▼
     |           +-----------------+    bpf_fib_lookup() +
     |           |                 |  bpf_clone_redirect()
     |           |    BPF clsact   +-------------------------► swpX
     |           |                 |
     |           +--------+--------+
     |                    |  skb->tstamp set according
     |                    |  to per-session Tx interval
     |                    |
     |                    ▼
     |           +-----------------+
     |           |                 |
     |           |    fq qdisc     |
     |           |                 |
     |           +--------+--------+
     |                    |  skb dequeued according to
     |          veth      |  skb->tstamp
     |         bfd_tx     |
     |       -------------|-------------
     |          veth      |
     |         bfd_rx     |
     |                    |
     |                    ▼
     |           +-----------------+
     |           |                 |
     |           |    BPF clsact   |
     |           |                 |
     |           +--------+--------+
     |                    |
     +--------------------+

Missing from the diagram are RPS on bfd_rx and XPS + mq + fqs on bfd_tx
in order to spread the BFD sessions (can be thousands with milliseconds
Tx intervals) across all available CPUs. Also missing is the handling of
neighbour resolution (i.e., upon BPF_FIB_LKUP_RET_NO_NEIGH) which is
deferred to user space.

The per-session BFD packet will be injected into this loop by user space
when the BFD session is first created.

The above loops works well, but we have identified two gaps with respect
to the bpf_fib_lookup() helper:

1. Forcing a lookup via a specific interface. User space can ask to form
a BFD session over a specific interface. In this case, we need the
bpf_fib_lookup() to resolve the destination MAC for us. This works well
with IPv4 when the BPF_FIB_LOOKUP_OUTPUT flag is specified, but IPv6
does not honor the oif and simply resolves the most specific route. This
is handled in patch #6.

2. Lookup for an IPv6 link-local address. Related to the previous gap,
user space can ask to form a single-hop BFD session over a specific
interface and specify an IPv6 link-local address as the remote peer
address. The bpf_fib_lookup() helper currently forbids lookups towards
such addresses. This is handled in patch #8.

[1] https://datatracker.ietf.org/doc/html/rfc5880
[2] https://datatracker.ietf.org/doc/html/rfc5881
[3] https://datatracker.ietf.org/doc/html/rfc5883
[4] https://docs.frrouting.org/en/latest/bfd.html#distributed-bfd

Ido Schimmel (9):
  selftests/bpf: fib_lookup: Force specific interface indexes
  selftests/bpf: fib_lookup: Enable forwarding on second net device
  selftests/bpf: fib_lookup: Allow parametrizing ifindex
  selftests/bpf: fib_lookup: Allow testing for expected ifindex
  selftests/bpf: fib_lookup: Add IPv4 output route tests
  bpf: fib_lookup: Honor oif in IPv6 output route lookups
  selftests/bpf: fib_lookup: Add IPv6 output route tests
  bpf: fib_lookup: Allow output lookups for IPv6 link-local addresses
  selftests/bpf: fib_lookup: Add IPv6 link-local tests

 net/core/filter.c                             |  12 +-
 .../selftests/bpf/prog_tests/fib_lookup.c     | 117 ++++++++++++++++--
 2 files changed, 118 insertions(+), 11 deletions(-)

-- 
2.53.0


             reply	other threads:[~2026-02-26  8:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-26  7:59 Ido Schimmel [this message]
2026-02-26  7:59 ` [RFC PATCH bpf-next 1/9] selftests/bpf: fib_lookup: Force specific interface indexes Ido Schimmel
2026-02-26  7:59 ` [RFC PATCH bpf-next 2/9] selftests/bpf: fib_lookup: Enable forwarding on second net device Ido Schimmel
2026-02-26  7:59 ` [RFC PATCH bpf-next 3/9] selftests/bpf: fib_lookup: Allow parametrizing ifindex Ido Schimmel
2026-02-26  7:59 ` [RFC PATCH bpf-next 4/9] selftests/bpf: fib_lookup: Allow testing for expected ifindex Ido Schimmel
2026-02-26  7:59 ` [RFC PATCH bpf-next 5/9] selftests/bpf: fib_lookup: Add IPv4 output route tests Ido Schimmel
2026-02-26  8:00 ` [RFC PATCH bpf-next 6/9] bpf: fib_lookup: Honor oif in IPv6 output route lookups Ido Schimmel
2026-02-26  8:41   ` bot+bpf-ci
2026-02-26 15:31     ` David Ahern
2026-02-26  8:00 ` [RFC PATCH bpf-next 7/9] selftests/bpf: fib_lookup: Add IPv6 output route tests Ido Schimmel
2026-02-26  8:00 ` [RFC PATCH bpf-next 8/9] bpf: fib_lookup: Allow output lookups for IPv6 link-local addresses Ido Schimmel
2026-02-26 15:36   ` David Ahern
2026-02-26  8:00 ` [RFC PATCH bpf-next 9/9] selftests/bpf: fib_lookup: Add IPv6 link-local tests Ido Schimmel
2026-02-26 17:14 ` [RFC PATCH bpf-next 0/9] bpf: fib_lookup: IPv6 output routes enhancements Alexei Starovoitov

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=20260226080003.524935-1-idosch@nvidia.com \
    --to=idosch@nvidia.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=sdf@fomichev.me \
    /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