Re: [PATCH v1 1/4] bpf: Add netpoll kfuncs for sending UDP packets

[Mahe Tardy <mahe.tardy@gmail.com>]

On Mon, May 11, 2026 at 02:05:26PM +0200, Daniel Borkmann wrote:
> On 5/11/26 10:53 AM, Mahe Tardy wrote:
> > From: Song Liu <song@kernel.org>
> > 
> > Add BPF kfuncs that allow BPF programs to send UDP packets via the
> > netpoll infrastructure. This provides a mechanism for BPF programs
> > (e.g., LSM hooks) to emit telemetry over UDP without depending on
> > the regular networking stack.
> > 
> > [...]
> > 
> > +config BPF_NETPOLL
> > +	bool "BPF netpoll UDP support"
> > +	depends on BPF_SYSCALL && NET
> > +	select NETPOLL
> > +	help
> > +	  Enable BPF kfuncs for sending UDP packets via netpoll.
> > +	  This allows BPF programs to send UDP packets from any
> > +	  context using the netpoll infrastructure.
> > +
> > +	  If unsure, say N.
> 
> Do we need the extra Kconfig knob? For most other BPF functionality we don't
> have such convention. BPF_NETPOLL could be a hidden config enabled when both
> BPF_SYSCALL && NETPOLL is enabled?

Okay I changed it to:

+config BPF_NETPOLL
+       def_bool BPF_SYSCALL && NETPOLL

So now we need to explicitely enable NETCONSOLE since NETPOL is also a
hidden config defined by:

config NETPOLL
	def_bool NETCONSOLE

I somehow initially wanted to define NETPOL by having def_bool
NETCONSOLE || BPF_NETPOLL but then we have a circular dependency...

> >   config NETPOLL
> >   	def_bool NETCONSOLE
> > 
> > diff --git a/include/linux/bpf_netpoll.h b/include/linux/bpf_netpoll.h
> > new file mode 100644
> > index 000000000000..b738032548c7
> > --- /dev/null
> > +++ b/include/linux/bpf_netpoll.h
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/* Copyright (c) 2026 Meta Platforms, Inc. and affiliates. */
> > +
> > +#ifndef _BPF_NETPOLL_H
> > +#define _BPF_NETPOLL_H
> > +
> > +#include <linux/types.h>
> > +
> > +#define BPF_NETPOLL_DEV_NAME_LEN 16	/* IFNAMSIZ */
> 
> Do we need this, can't we just reuse IFNAMSIZ?

We don't really need it, done!

> > +/**
> > + * struct bpf_netpoll_opts - BPF netpoll initialization parameters
> > + * @dev_name:	Network device name (e.g. "eth0"), null-terminated.
> > + * @local_ip:	Local IPv4 address in network byte order. 0 = auto-detect.
> > + * @remote_ip:	Remote IPv4 address in network byte order.
> > + * @local_port:	Local UDP port in host byte order.
> > + * @remote_port: Remote UDP port in host byte order.
> > + * @remote_mac:	Remote MAC address (6 bytes).
> > + * @ipv6:	Set to 1 for IPv6, 0 for IPv4.
> > + * @reserved:	Must be zero. Reserved for future use.
> > + * @local_ip6:	Local IPv6 address (16 bytes). Used when ipv6=1.
> > + *		Zero = auto-detect.
> > + * @remote_ip6:	Remote IPv6 address (16 bytes). Used when ipv6=1.
> > + */
> > +struct bpf_netpoll_opts {
> > +	char dev_name[BPF_NETPOLL_DEV_NAME_LEN];
> > +	__be32 local_ip;
> > +	__be32 remote_ip;
> > +	__u16 local_port;
> > +	__u16 remote_port;
> > +	__u8 remote_mac[6];
> > +	__u8 ipv6;
> > +	__u8 reserved;
> > +	__u8 local_ip6[16];
> > +	__u8 remote_ip6[16];
> > +};
> 
> Could we detangle this a bit and structure the design similar to what was
> done for the bpf fib lookup helpers? __u8 family and then union.

Yeah I think initially it was heavily inspired by the struct netpoll for
IPv6 boolean but they have the union, let's do it, I wrote this one that
is similar to the fib lookup params:

struct bpf_netpoll_opts {
	char dev_name[IFNAMSIZ];
	__u8 family;
	__u8 reserved;
	__u16 local_port;
	__u16 remote_port;
	__u8 remote_mac[ETH_ALEN];

	union {
		__be32 ipv4_local;
		__u32 ipv6_local[4];  /* in6_addr; network order */
	};

	union {
		__be32 ipv4_remote;
		__u32 ipv6_remote[4];  /* in6_addr; network order */
	};
};

Also used family instead of the bool with this in the kfunc:

switch (opts->family) {
case AF_INET:
	bnp->np.local_ip.ip = opts->ipv4_local;
	bnp->np.remote_ip.ip = opts->ipv4_remote;
	break;
case AF_INET6:
	memcpy(&bnp->np.local_ip.in6, opts->ipv6_local,
	       sizeof(struct in6_addr));
	memcpy(&bnp->np.remote_ip.in6, opts->ipv6_remote,
	       sizeof(struct in6_addr));
	bnp->np.ipv6 = true;
	break;
default:
	*err = -EAFNOSUPPORT;
	return NULL;
}

> Is the remote_mac strictly needed? 

I think it's indeed needed since netpoll is pushing the MAC address in
the skb at the send step. It's not reusing the network stack for lookup.
I think netconsole is using the broadcast address by default, maybe the
kfunc could default to it as well.

> Feels a bit like a burden, maybe for the
> selftest, we should first do a bpf_fib_lookup before the bpf_netpoll_create
> so that the use case where the user only cares about giving remote_ip/remote_port
> and maybe local_port (e.g. to as indicator for different event types and/or
> RSS hashing) works, but everything else is derived via kernel fib lookup.

Yeah that would be nice but then it would mean we need to call fib
lookup from the SYSCALL programs without any network context so I'm not
sure how it would look like.

> Thanks,
> Daniel

Thanks for the review!
Mahe