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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue May 12, 2026 at 6:53 AM PDT, Jakub Kicinski wrote:
>> >> I like this netpoll approach way more then creating and keeping proper socket
>> >> within bpf and all head aches of keeping it around and doing send from
>> >> good context. With netpoll all of these issues are gone.
>> >> Just bpf_netpoll_send_udp() from anywhere and it works just like it does
>> >> for dmesg.  
>> >
>> > No, netpoll is high risk / brittle and tightly integrated with NAPI.
>> >
>> > "I don't want to run a tiny user space program" is nowhere near strong
>> > enough justification to expose this API. SMH.  
>> 
>> No. Nothing to do with 'user space prog'.
>
> I'm sorry, are you saying that the motivation in the cover letter is
> not the motivation? It'd be great if someone could reveal the real
> motivation then.

AI makes commit logs sound very convincing, so I don't read them anymore
to avoid bias. Only looking at the code.
And what I see in this set is a facility for emergency notifications
that is safe to use in any context.

If people bolt crypto on top and make a toy prototype out of it
it doesn't take away from usefulness of sending UDP packets out.

I want to use it out of bpf core to notify of things like divide by zero,
arena fault, etc. Currently they are sent via bpf_stream, but
user space has to be there to pick up from the stream.
We cannot use printk, since it's not safe.
So netcons is the only option available today for 'bad things happen'
notifications.
Theoretically con->write_atomic() can be wrapped in such helper/kfunc
that both bpf core and bpf progs can call.
progs also need emergency notifications.
Like sched-ext might detect something bad and notify.
But at the end netconsole_write() is netpoll_send_udp(),
so more natural and simpler to just use that.

> In kernel sockets are used broadly. I accept that it's more work
> for you but it's also the correct way to go about this if you want 
> to send traffic from BPF.

proper sockets and full TCP/UDP back and forth is a different use case.
Maybe it will work for Mahe/Liam. I don't know.
I'm arguing that emergency UDP is necessary too.
We can skip netpoll_send_udp() and let bpf core prepare skb
earlier in a good context, then at div-by-0 time populate it
with a message and call netpoll_send_skb().
Looks like netcons, bridge, vlan are using it, so why not let
bpf core use it too?
__netpoll_send_skb() is the main value here because
it's all trylock based at every step.
The div-by-0 notification using normal sockets would have to be
done async and that's the main downside.
We'd need to irq_work, then schedule_work and then send it via socket.
Way too many steps to do in emergency. If sched-ext messed it up
kthread may or may not wakeup.