[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 <tom@herbertland.com>]

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