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

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

[Frantisek Borsik]

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

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

[David P. Reed]

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] Re: [Cake] XDP2 is here - from one and only Tom Herbert (almost to the date, 10 years after XDP was released)

[Frantisek Borsik]

Thanks a lot, David.

I have asked Tom if he wants to join us and he should be here to chat with
us now.

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


On Tue, Sep 9, 2025 at 10:25 PM David P. Reed <dpreed@deepplum.com> 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] Re: [Cake] Re: XDP2 is here - from one and only Tom Herbert (almost to the date, 10 years after XDP was released)

[Tom Herbert]

On Tue, Sep 9, 2025, 5:03 PM Frantisek Borsik <frantisek.borsik@gmail.com>
wrote:

> Thanks a lot, David.
>
> I have asked Tom if he wants to join us and he should be here to chat with
> us now.
>
> 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
>
>
> On Tue, Sep 9, 2025 at 10:25 PM David P. Reed <dpreed@deepplum.com> 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.
>

HI David,

The idea is you could write the code in XDP2 and it would be compiled to
DPDK or eBPF and the compiler would handle the optimizations.


> >
> >
> >
> > 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).


Think of XDP2 as the generalization of XDP to go beyond just the kernel.
The idea is that the user writes their datapath code once and they compile
it to run in whatever targets they have-- DPDK, P4, other programmable
hardware, and yes XDP/eBPF. It's really not limited to kernel networking.

As for the name XDP2, when we created XDP, eXpress DataPath, my vision was
that it would be implementation agnostic. eBPF was the first instantiation
for practicality, but now ten years later I think we can realize the
initial vision.

Tom



>
> > 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
> > >
> >
> _______________________________________________
> Cake mailing list -- cake@lists.bufferbloat.net
> To unsubscribe send an email to cake-leave@lists.bufferbloat.net
>

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

[BeckW]

Interesting work! One problem of P4 is that the networking hardware varies so much in number of resources (queues, schedulers, policers, counters, table memory) that the code inevitably becomes tied to a certain system.
It will be difficult to abstract the peculiarities of systems -- eg Broadcom 88800 vs linux kernel -- in a good way.

Wolfgang

-----Ursprüngliche Nachricht-----
Von: Tom Herbert via Bloat <bloat@lists.bufferbloat.net> 
Gesendet: Dienstag, 9. September 2025 23:37
An: Frantisek Borsik <frantisek.borsik@gmail.com>
Cc: David P. Reed <dpreed@deepplum.com>; Cake List <cake@lists.bufferbloat.net>; codel@lists.bufferbloat.net; bloat <bloat@lists.bufferbloat.net>; Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>
Betreff: [Bloat] Re: [Cake] Re: XDP2 is here - from one and only Tom Herbert (almost to the date, 10 years after XDP was released)

On Tue, Sep 9, 2025, 5:03 PM Frantisek Borsik <frantisek.borsik@gmail.com>
wrote:

> Thanks a lot, David.
>
> I have asked Tom if he wants to join us and he should be here to chat 
> with us now.
>
> All the best,
>
> Frank
>
> Frantisek (Frank) Borsik
>
>
> *In loving memory of Dave Täht: *1965-2025
>
> https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibr
> eqos.io%2F2025%2F04%2F01%2Fin-loving-memory-of-dave%2F&data=05%7C02%7C
> BeckW%40telekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604c
> f68b04a5eeb25f5c4f%7C0%7C0%7C638930853609276702%7CUnknown%7CTWFpbGZsb3
> d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TAA6NdEkB3KQQt8UhKqs3ZKuLj
> N7A9h9J9FAjNRDDuU%3D&reserved=0
>
>
> https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> linkedin.com%2Fin%2Ffrantisekborsik&data=05%7C02%7CBeckW%40telekom.de%
> 7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%
> 7C0%7C0%7C638930853609297031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> 3D%3D%7C0%7C%7C%7C&sdata=ucL7U%2FQ81ks09nVEGUbe%2FFq1rhJNLaegicv%2FLCV
> cIlg%3D&reserved=0
>
> Signal, Telegram, WhatsApp: +421919416714
>
> iMessage, mobile: +420775230885
>
> Skype: casioa5302ca
>
> frantisek.borsik@gmail.com
>
>
> On Tue, Sep 9, 2025 at 10:25 PM David P. Reed <dpreed@deepplum.com> 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.
>

HI David,

The idea is you could write the code in XDP2 and it would be compiled to DPDK or eBPF and the compiler would handle the optimizations.


> >
> >
> >
> > 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).


Think of XDP2 as the generalization of XDP to go beyond just the kernel.
The idea is that the user writes their datapath code once and they compile it to run in whatever targets they have-- DPDK, P4, other programmable hardware, and yes XDP/eBPF. It's really not limited to kernel networking.

As for the name XDP2, when we created XDP, eXpress DataPath, my vision was that it would be implementation agnostic. eBPF was the first instantiation for practicality, but now ten years later I think we can realize the initial vision.

Tom



>
> > 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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedi
> um.com%2F%40tom_84912%2Fxdp2-this-changes-everything-at-least-for-ai-m
> l-infrastructure-850c1ba82771&data=05%7C02%7CBeckW%40telekom.de%7C299d
> 64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C
> 0%7C638930853609308950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=RTLHTVFR540C8Psr73uiuRvkx1sSyjmlUIICEHFj0HA%3D&rese
> rved=0
> > >
> > >
> > > All the best,
> > >
> > > Frank
> > >
> > > Frantisek (Frank) Borsik
> > >
> > >
> > > *In loving memory of Dave Täht: *1965-2025
> > >
> > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > libreqos.io%2F2025%2F04%2F01%2Fin-loving-memory-of-dave%2F&data=05
> > > %7C02%7CBeckW%40telekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbd
> > > e4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638930853609323027%7CUnkn
> > > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> > > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=98
> > > musUCMTZR4ID%2Bo6GYxWOX99aiYBspBUdh%2BNV1fzwc%3D&reserved=0
> > >
> > >
> > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > www.linkedin.com%2Fin%2Ffrantisekborsik&data=05%7C02%7CBeckW%40tel
> > > ekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a
> > > 5eeb25f5c4f%7C0%7C0%7C638930853609334239%7CUnknown%7CTWFpbGZsb3d8e
> > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> > > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rD47zFeLVV1YDqMc5SO0
> > > xGWEOTrE3FOYv0mOqGF%2FW4%3D&reserved=0
> > >
> > > 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
> > >
> >
> _______________________________________________
> Cake mailing list -- cake@lists.bufferbloat.net To unsubscribe send an 
> email to cake-leave@lists.bufferbloat.net
>
_______________________________________________
Bloat mailing list -- bloat@lists.bufferbloat.net To unsubscribe send an email to bloat-leave@lists.bufferbloat.net

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

[Tom Herbert]

On Wed, Sep 10, 2025, 1:54 AM <BeckW@telekom.de> wrote:

> Interesting work! One problem of P4 is that the networking hardware varies
> so much in number of resources (queues, schedulers, policers, counters,
> table memory) that the code inevitably becomes tied to a certain system.
> It will be difficult to abstract the peculiarities of systems -- eg
> Broadcom 88800 vs linux kernel -- in a good way.
>

Hi Wolfgang

>
Yes, the non-portability of P4 code between different architectures has
been raised as an issue. I believe this is subset of the general problem
that we need to deal with differing resource constraints across targets
(like different memory resources, hardware accelerators, table sizes, etc
). It should be a problem of resource constraints, and not differences in
core functionality supported by the targets

I think there's three possibilities:

1) We create an image and attempt to resolve the resource constraints at
runtime (load time). Determine the resources and run with those. It's
possible that a HW configuration doesn't have sufficient resources to meet
the programmer's requirements in which case we may have to inform the user
the program can't run (e.g.if the programmer wants line rate encryption,
but there's no HW accelerators then the program requirements can't be met
and the program can't run on that target).
2) Recompile the backend to the different targets. This is needed when the
executable is incompatible between targets. The goal is to still be
transparent to the user, but we still need to meet the requirement of the
application.
3) Change the source code if the hardware peculiarities are not transparent
to program source. Obviously, this is the least preferred option, but if
there's no alternative then the goal here would be to isolate the target
specific code as much as possible. Hopefully, the vast majority of program
code is target agnostic and there's just a little glue code for each target.

Tom



> Wolfgang
>
> -----Ursprüngliche Nachricht-----
> Von: Tom Herbert via Bloat <bloat@lists.bufferbloat.net>
> Gesendet: Dienstag, 9. September 2025 23:37
> An: Frantisek Borsik <frantisek.borsik@gmail.com>
> Cc: David P. Reed <dpreed@deepplum.com>; Cake List <
> cake@lists.bufferbloat.net>; codel@lists.bufferbloat.net; bloat <
> bloat@lists.bufferbloat.net>; Jeremy Austin via Rpm <
> rpm@lists.bufferbloat.net>
> Betreff: [Bloat] Re: [Cake] Re: XDP2 is here - from one and only Tom
> Herbert (almost to the date, 10 years after XDP was released)
>
> On Tue, Sep 9, 2025, 5:03 PM Frantisek Borsik <frantisek.borsik@gmail.com>
> wrote:
>
> > Thanks a lot, David.
> >
> > I have asked Tom if he wants to join us and he should be here to chat
> > with us now.
> >
> > All the best,
> >
> > Frank
> >
> > Frantisek (Frank) Borsik
> >
> >
> > *In loving memory of Dave Täht: *1965-2025
> >
> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibr
> > eqos.io%2F2025%2F04%2F01%2Fin-loving-memory-of-dave%2F&data=05%7C02%7C
> > BeckW%40telekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604c
> > f68b04a5eeb25f5c4f%7C0%7C0%7C638930853609276702%7CUnknown%7CTWFpbGZsb3
> > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TAA6NdEkB3KQQt8UhKqs3ZKuLj
> > N7A9h9J9FAjNRDDuU%3D&reserved=0
> >
> >
> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > linkedin.com%2Fin%2Ffrantisekborsik&data=05%7C02%7CBeckW%40telekom.de%
> > 7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%
> > 7C0%7C0%7C638930853609297031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
> > 3D%3D%7C0%7C%7C%7C&sdata=ucL7U%2FQ81ks09nVEGUbe%2FFq1rhJNLaegicv%2FLCV
> > cIlg%3D&reserved=0
> >
> > Signal, Telegram, WhatsApp: +421919416714
> >
> > iMessage, mobile: +420775230885
> >
> > Skype: casioa5302ca
> >
> > frantisek.borsik@gmail.com
> >
> >
> > On Tue, Sep 9, 2025 at 10:25 PM David P. Reed <dpreed@deepplum.com>
> 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.
> >
>
> HI David,
>
> The idea is you could write the code in XDP2 and it would be compiled to
> DPDK or eBPF and the compiler would handle the optimizations.
>
>
> > >
> > >
> > >
> > > 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).
>
>
> Think of XDP2 as the generalization of XDP to go beyond just the kernel.
> The idea is that the user writes their datapath code once and they compile
> it to run in whatever targets they have-- DPDK, P4, other programmable
> hardware, and yes XDP/eBPF. It's really not limited to kernel networking.
>
> As for the name XDP2, when we created XDP, eXpress DataPath, my vision was
> that it would be implementation agnostic. eBPF was the first instantiation
> for practicality, but now ten years later I think we can realize the
> initial vision.
>
> Tom
>
>
>
> >
> > > 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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedi
> > um.com%2F%40tom_84912%2Fxdp2-this-changes-everything-at-least-for-ai-m
> > l-infrastructure-850c1ba82771&data=05%7C02%7CBeckW%40telekom.de%7C299d
> > 64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C
> > 0%7C638930853609308950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> > 7C0%7C%7C%7C&sdata=RTLHTVFR540C8Psr73uiuRvkx1sSyjmlUIICEHFj0HA%3D&rese
> > rved=0
> > > >
> > > >
> > > > All the best,
> > > >
> > > > Frank
> > > >
> > > > Frantisek (Frank) Borsik
> > > >
> > > >
> > > > *In loving memory of Dave Täht: *1965-2025
> > > >
> > > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > libreqos.io%2F2025%2F04%2F01%2Fin-loving-memory-of-dave%2F&data=05
> > > > %7C02%7CBeckW%40telekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbd
> > > > e4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638930853609323027%7CUnkn
> > > > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> > > > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=98
> > > > musUCMTZR4ID%2Bo6GYxWOX99aiYBspBUdh%2BNV1fzwc%3D&reserved=0
> > > >
> > > >
> > > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > www.linkedin.com%2Fin%2Ffrantisekborsik&data=05%7C02%7CBeckW%40tel
> > > > ekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a
> > > > 5eeb25f5c4f%7C0%7C0%7C638930853609334239%7CUnknown%7CTWFpbGZsb3d8e
> > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
> > > > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rD47zFeLVV1YDqMc5SO0
> > > > xGWEOTrE3FOYv0mOqGF%2FW4%3D&reserved=0
> > > >
> > > > 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
> > > >
> > >
> > _______________________________________________
> > Cake mailing list -- cake@lists.bufferbloat.net To unsubscribe send an
> > email to cake-leave@lists.bufferbloat.net
> >
> _______________________________________________
> Bloat mailing list -- bloat@lists.bufferbloat.net To unsubscribe send an
> email to bloat-leave@lists.bufferbloat.net
>

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

[Tom Herbert]

Cc XDP2 list

On Wed, Sep 10, 2025, 6:59 AM Tom Herbert <tom@herbertland.com> wrote:

>
>
> On Wed, Sep 10, 2025, 1:54 AM <BeckW@telekom.de> wrote:
>
>> Interesting work! One problem of P4 is that the networking hardware
>> varies so much in number of resources (queues, schedulers, policers,
>> counters, table memory) that the code inevitably becomes tied to a certain
>> system.
>> It will be difficult to abstract the peculiarities of systems -- eg
>> Broadcom 88800 vs linux kernel -- in a good way.
>>
>
> Hi Wolfgang
>
>>
> Yes, the non-portability of P4 code between different architectures has
> been raised as an issue. I believe this is subset of the general problem
> that we need to deal with differing resource constraints across targets
> (like different memory resources, hardware accelerators, table sizes, etc
> ). It should be a problem of resource constraints, and not differences in
> core functionality supported by the targets
>
> I think there's three possibilities:
>
> 1) We create an image and attempt to resolve the resource constraints at
> runtime (load time). Determine the resources and run with those. It's
> possible that a HW configuration doesn't have sufficient resources to meet
> the programmer's requirements in which case we may have to inform the user
> the program can't run (e.g.if the programmer wants line rate encryption,
> but there's no HW accelerators then the program requirements can't be met
> and the program can't run on that target).
> 2) Recompile the backend to the different targets. This is needed when the
> executable is incompatible between targets. The goal is to still be
> transparent to the user, but we still need to meet the requirement of the
> application.
> 3) Change the source code if the hardware peculiarities are not
> transparent to program source. Obviously, this is the least preferred
> option, but if there's no alternative then the goal here would be to
> isolate the target specific code as much as possible. Hopefully, the vast
> majority of program code is target agnostic and there's just a little glue
> code for each target.
>
> Tom
>
>
>
>> Wolfgang
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Tom Herbert via Bloat <bloat@lists.bufferbloat.net>
>> Gesendet: Dienstag, 9. September 2025 23:37
>> An: Frantisek Borsik <frantisek.borsik@gmail.com>
>> Cc: David P. Reed <dpreed@deepplum.com>; Cake List <
>> cake@lists.bufferbloat.net>; codel@lists.bufferbloat.net; bloat <
>> bloat@lists.bufferbloat.net>; Jeremy Austin via Rpm <
>> rpm@lists.bufferbloat.net>
>> Betreff: [Bloat] Re: [Cake] Re: XDP2 is here - from one and only Tom
>> Herbert (almost to the date, 10 years after XDP was released)
>>
>> On Tue, Sep 9, 2025, 5:03 PM Frantisek Borsik <frantisek.borsik@gmail.com
>> >
>> wrote:
>>
>> > Thanks a lot, David.
>> >
>> > I have asked Tom if he wants to join us and he should be here to chat
>> > with us now.
>> >
>> > All the best,
>> >
>> > Frank
>> >
>> > Frantisek (Frank) Borsik
>> >
>> >
>> > *In loving memory of Dave Täht: *1965-2025
>> >
>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flibr
>> > eqos.io%2F2025%2F04%2F01%2Fin-loving-memory-of-dave%2F&data=05%7C02%7C
>> > BeckW%40telekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604c
>> > f68b04a5eeb25f5c4f%7C0%7C0%7C638930853609276702%7CUnknown%7CTWFpbGZsb3
>> > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
>> > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TAA6NdEkB3KQQt8UhKqs3ZKuLj
>> > N7A9h9J9FAjNRDDuU%3D&reserved=0
>> >
>> >
>> > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> > linkedin.com%2Fin%2Ffrantisekborsik&data=05%7C02%7CBeckW%40telekom.de%
>> > 7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%
>> > 7C0%7C0%7C638930853609297031%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiO
>> > nRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%
>> > 3D%3D%7C0%7C%7C%7C&sdata=ucL7U%2FQ81ks09nVEGUbe%2FFq1rhJNLaegicv%2FLCV
>> > cIlg%3D&reserved=0
>> >
>> > Signal, Telegram, WhatsApp: +421919416714
>> >
>> > iMessage, mobile: +420775230885
>> >
>> > Skype: casioa5302ca
>> >
>> > frantisek.borsik@gmail.com
>> >
>> >
>> > On Tue, Sep 9, 2025 at 10:25 PM David P. Reed <dpreed@deepplum.com>
>> 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.
>> >
>>
>> HI David,
>>
>> The idea is you could write the code in XDP2 and it would be compiled to
>> DPDK or eBPF and the compiler would handle the optimizations.
>>
>>
>> > >
>> > >
>> > >
>> > > 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).
>>
>>
>> Think of XDP2 as the generalization of XDP to go beyond just the kernel.
>> The idea is that the user writes their datapath code once and they
>> compile it to run in whatever targets they have-- DPDK, P4, other
>> programmable hardware, and yes XDP/eBPF. It's really not limited to kernel
>> networking.
>>
>> As for the name XDP2, when we created XDP, eXpress DataPath, my vision
>> was that it would be implementation agnostic. eBPF was the first
>> instantiation for practicality, but now ten years later I think we can
>> realize the initial vision.
>>
>> Tom
>>
>>
>>
>> >
>> > > 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://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedi
>> > um.com%2F%40tom_84912%2Fxdp2-this-changes-everything-at-least-for-ai-m
>> > l-infrastructure-850c1ba82771&data=05%7C02%7CBeckW%40telekom.de%7C299d
>> > 64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C
>> > 0%7C638930853609308950%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
>> > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
>> > 7C0%7C%7C%7C&sdata=RTLHTVFR540C8Psr73uiuRvkx1sSyjmlUIICEHFj0HA%3D&rese
>> > rved=0
>> > > >
>> > > >
>> > > > All the best,
>> > > >
>> > > > Frank
>> > > >
>> > > > Frantisek (Frank) Borsik
>> > > >
>> > > >
>> > > > *In loving memory of Dave Täht: *1965-2025
>> > > >
>> > > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> > > > libreqos.io%2F2025%2F04%2F01%2Fin-loving-memory-of-dave%2F&data=05
>> > > > %7C02%7CBeckW%40telekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbd
>> > > > e4dffc4b604cf68b04a5eeb25f5c4f%7C0%7C0%7C638930853609323027%7CUnkn
>> > > > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
>> > > > OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=98
>> > > > musUCMTZR4ID%2Bo6GYxWOX99aiYBspBUdh%2BNV1fzwc%3D&reserved=0
>> > > >
>> > > >
>> > > > https://deu01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> > > > www.linkedin.com%2Fin%2Ffrantisekborsik&data=05%7C02%7CBeckW%40tel
>> > > > ekom.de%7C299d64b9b76b4d4cf88b08ddf039e105%7Cbde4dffc4b604cf68b04a
>> > > > 5eeb25f5c4f%7C0%7C0%7C638930853609334239%7CUnknown%7CTWFpbGZsb3d8e
>> > > > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> > > > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0rD47zFeLVV1YDqMc5SO0
>> > > > xGWEOTrE3FOYv0mOqGF%2FW4%3D&reserved=0
>> > > >
>> > > > 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
>> > > >
>> > >
>> > _______________________________________________
>> > Cake mailing list -- cake@lists.bufferbloat.net To unsubscribe send an
>> > email to cake-leave@lists.bufferbloat.net
>> >
>> _______________________________________________
>> Bloat mailing list -- bloat@lists.bufferbloat.net To unsubscribe send an
>> email to bloat-leave@lists.bufferbloat.net
>>
>