[Codel] Re: [Rpm] Re: [Cake] XDP2 is here - from one and only Tom Herbert (almost to the date, 10 years after XDP was released)

[Robert McMahon <rjmcmahon@rjmcmahon.com>]

Hi David,

This may be relevant to Fi-Wi. The units won't be 802.3 packets but rather
802.11 transmits/receives (including aggregations, and MU
transmtits/receives) and maybe on multiple radio heads for redundancy. (The
first pilot is 24 remote radio heads)

All in user space would be great.

Any thoughts on that?

Bob

EBFP or DPDK need not apply per "the fundamental limitation is that *neither
approach gives you raw 802.11 access in normal operational mode* - that
requires monitor mode or specialized hardware/drivers."

When dealing with 802.11 packets *not in monitor mode* (i.e., normal
operational mode), there are significant differences between DPDK and eBPF
approaches:
eBPF with 802.11 (Non-Monitor Mode)

*What you get:*

   - Already *decapsulated Ethernet frames* - the 802.11 headers are
   stripped by the wireless driver
   - Standard network stack integration
   - Access via XDP, TC, socket filters, etc.
   - *No access to 802.11-specific metadata* like signal strength, retry
   flags, or wireless management frames

*Limitations:*

   - Cannot see 802.11 management/control frames (beacons, probe requests,
   etc.)
   - No access to wireless-specific information (RSSI, channel, etc.)
   - Limited to the data payload that survives 802.11 → Ethernet conversion

DPDK with 802.11 (Non-Monitor Mode)

*Similar limitations:*

   - DPDK also receives *post-processed Ethernet frames* from wireless NICs
   in normal mode
   - The wireless driver still handles 802.11 processing before DPDK sees
   the packets
   - *No raw 802.11 frame access* unless the hardware/driver specifically
   supports it

*DPDK advantages:*

   - *Higher packet rates* - can handle more packets per second
   - *Lower latency* - bypasses kernel networking stack
   - *More CPU control* - dedicated cores, polling vs interrupts
   - Better for high-throughput wireless applications

Key Insight

In *non-monitor mode*, both DPDK and eBPF are working with the *same input*:
Ethernet frames that have already been converted from 802.11 by the
wireless driver. The 802.11-specific information is already gone.
When to Choose Which

*Choose eBPF when:*

   - You need kernel integration
   - Working with existing network stack
   - Moderate packet rates
   - Want to leverage existing eBPF tooling

*Choose DPDK when:*

   - High packet rates are critical
   - You need minimum latency
   - Can dedicate CPU cores
   - Building a specialized wireless application

The fundamental limitation is that *neither approach gives you raw 802.11
access in normal operational mode* - that requires monitor mode or
specialized hardware/drivers.

On Tue, Sep 9, 2025 at 1:25 PM David P. Reed via Rpm <
rpm@lists.bufferbloat.net> wrote:

>
> Hi Frank -
>
> I think it is interesting as a concept. A project I am advising has been
> using DPDK very effectively to get rid of the huge path and locking delays
> in the current Linux network stack. XDP2 could be supported in a ring3
> (user) address space, achieving a similar result.
>
> But I don't think XDP2 is going that direction - so it may be stuckinto
> the mess of kernel space networking. Adding eBPF only has made this more of
> a mess, by the way (and adding a new "compiler" that needs to be veriried
> as safe for the kernel).
>
> I will be watching how this evolves.
>
> David
>
> On Tuesday, September 9, 2025 06:32, "Frantisek Borsik" <
> frantisek.borsik@gmail.com> said:
>
>
>
> > Hello to all,
> >
> > Looks interesting:
> >
> https://medium.com/@tom_84912/xdp2-this-changes-everything-at-least-for-ai-ml-infrastructure-850c1ba82771
> >
> >
> > All the best,
> >
> > Frank
> >
> > Frantisek (Frank) Borsik
> >
> >
> > *In loving memory of Dave Täht: *1965-2025
> >
> > https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
> >
> >
> > https://www.linkedin.com/in/frantisekborsik
> >
> > Signal, Telegram, WhatsApp: +421919416714
> >
> > iMessage, mobile: +420775230885
> >
> > Skype: casioa5302ca
> >
> > frantisek.borsik@gmail.com
> > _______________________________________________
> > Cake mailing list -- cake@lists.bufferbloat.net
> > To unsubscribe send an email to cake-leave@lists.bufferbloat.net
> >
> _______________________________________________
> Rpm mailing list -- rpm@lists.bufferbloat.net
> To unsubscribe send an email to rpm-leave@lists.bufferbloat.net
>