[Public] Inline as <VJ2>... (was html, sorry) ________________________________________ From: John Fastabend <john.fastabend@xxxxxxxxx> Sent: Tuesday, May 28, 2024 1:17 PM To: Jain, Vipin <Vipin.Jain@xxxxxxx>; Singhai, Anjali <anjali.singhai@xxxxxxxxx>; Hadi Salim, Jamal <jhs@xxxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx> Cc: Paolo Abeni <pabeni@xxxxxxxxxx>; Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>; Network Development <netdev@xxxxxxxxxxxxxxx>; Chatterjee, Deb <deb.chatterjee@xxxxxxxxx>; Limaye, Namrata <namrata.limaye@xxxxxxxxx>; tom Herbert <tom@xxxxxxxxxx>; Marcelo Ricardo Leitner <mleitner@xxxxxxxxxx>; Shirshyad, Mahesh <Mahesh.Shirshyad@xxxxxxx>; Osinski, Tomasz <tomasz.osinski@xxxxxxxxx>; Jiri Pirko <jiri@xxxxxxxxxxx>; Cong Wang <xiyou.wangcong@xxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet <edumazet@xxxxxxxxxx>; Vlad Buslov <vladbu@xxxxxxxxxx>; Simon Horman <horms@xxxxxxxxxx>; Khalid Manaa <khalidm@xxxxxxxxxx>; Toke Høiland-Jørgensen <toke@xxxxxxxxxx>; Victor Nogueira <victor@xxxxxxxxxxxx>; Tammela, Pedro <pctammela@xxxxxxxxxxxx>; Daly, Dan <dan.daly@xxxxxxxxx>; Andy Fingerhut <andy.fingerhut@xxxxxxxxx>; Sommers, Chris <chris.sommers@xxxxxxxxxxxx>; Matty Kadosh <mattyk@xxxxxxxxxx>; bpf <bpf@xxxxxxxxxxxxxxx>; lwn@xxxxxxx <lwn@xxxxxxx> Subject: Re: On the NACKs on P4TC patches Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Jain, Vipin wrote: > [AMD Official Use Only - AMD Internal Distribution Only] > > My apologies, earlier email used html and was blocked by the list... > My response at the bottom as "VJ>" > > ________________________________________ > From: Jain, Vipin <Vipin.Jain@xxxxxxx> > Sent: Friday, May 24, 2024 2:28 PM > To: Singhai, Anjali <anjali.singhai@xxxxxxxxx>; Hadi Salim, Jamal <jhs@xxxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx> > Cc: Paolo Abeni <pabeni@xxxxxxxxxx>; Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>; Network Development <netdev@xxxxxxxxxxxxxxx>; Chatterjee, Deb <deb.chatterjee@xxxxxxxxx>; Limaye, Namrata <namrata.limaye@xxxxxxxxx>; tom Herbert <tom@xxxxxxxxxx>; Marcelo Ricardo Leitner <mleitner@xxxxxxxxxx>; Shirshyad, Mahesh <Mahesh.Shirshyad@xxxxxxx>; Osinski, Tomasz <tomasz.osinski@xxxxxxxxx>; Jiri Pirko <jiri@xxxxxxxxxxx>; Cong Wang <xiyou.wangcong@xxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet <edumazet@xxxxxxxxxx>; Vlad Buslov <vladbu@xxxxxxxxxx>; Simon Horman <horms@xxxxxxxxxx>; Khalid Manaa <khalidm@xxxxxxxxxx>; Toke Høiland-Jørgensen <toke@xxxxxxxxxx>; Victor Nogueira <victor@xxxxxxxxxxxx>; Tammela, Pedro <pctammela@xxxxxxxxxxxx>; Daly, Dan <dan.daly@xxxxxxxxx>; Andy Fingerhut <andy.fingerhut@xxxxxxxxx>; Sommers, Chris <chris.sommers@xxxxxxxxxxxx>; Matty Kadosh <mattyk@xxxxxxxxxx>; bpf <bpf@xxxxxxxxxxxxxxx>; lwn@xxxxxxx <lwn@xxxxxxx> > Subject: Re: On the NACKs on P4TC patches > > [AMD Official Use Only - AMD Internal Distribution Only] > > > I can ascertain (from AMD) that we have stated interest in, and are in full support of P4TC. > > Happy to elaborate more if needed. > > Thank you, > Vipin Jain > Sr Fellow Engineer, AMD > ________________________________________ > From: Singhai, Anjali <anjali.singhai@xxxxxxxxx> > Sent: Wednesday, May 22, 2024 5:30 PM > To: Hadi Salim, Jamal <jhs@xxxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx> > Cc: Paolo Abeni <pabeni@xxxxxxxxxx>; Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>; Network Development <netdev@xxxxxxxxxxxxxxx>; Chatterjee, Deb <deb.chatterjee@xxxxxxxxx>; Limaye, Namrata <namrata.limaye@xxxxxxxxx>; tom Herbert <tom@xxxxxxxxxx>; Marcelo Ricardo Leitner <mleitner@xxxxxxxxxx>; Shirshyad, Mahesh <Mahesh.Shirshyad@xxxxxxx>; Osinski, Tomasz <tomasz.osinski@xxxxxxxxx>; Jiri Pirko <jiri@xxxxxxxxxxx>; Cong Wang <xiyou.wangcong@xxxxxxxxx>; David S. Miller <davem@xxxxxxxxxxxxx>; Eric Dumazet <edumazet@xxxxxxxxxx>; Vlad Buslov <vladbu@xxxxxxxxxx>; Simon Horman <horms@xxxxxxxxxx>; Khalid Manaa <khalidm@xxxxxxxxxx>; Toke Høiland-Jørgensen <toke@xxxxxxxxxx>; Victor Nogueira <victor@xxxxxxxxxxxx>; Tammela, Pedro <pctammela@xxxxxxxxxxxx>; Jain, Vipin <Vipin.Jain@xxxxxxx>; Daly, Dan <dan.daly@xxxxxxxxx>; Andy Fingerhut <andy.fingerhut@xxxxxxxxx>; Sommers, Chris <chris.sommers@xxxxxxxxxxxx>; Matty Kadosh <mattyk@xxxxxxxxxx>; bpf <bpf@xxxxxxxxxxxxxxx>; lwn@xxxxxxx <lwn@xxxxxxx> > Subject: RE: On the NACKs on P4TC patches > > Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. > > > On Wed, May 22, 2024 at 6:19 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > >> AFAICT there's some but not very strong support for P4TC, > > On Wed, May 22, 2024 at 4:04 PM Jamal Hadi Salim <jhs@xxxxxxxxxxxx > wrote: > >I dont agree. Paolo asked this question and afaik Intel, AMD (both build P4-native NICs) and the folks interested in the MS DASH project >responded saying they are in support. Look at who is being Cced. A lot of these folks who attend biweekly discussion calls on P4TC. >Sample: > >https://lore.kernel.org/netdev/IA0PR17MB7070B51A955FB8595FFBA5FB965E2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > FWIW, Intel is in full support of P4TC as we have stated several times in the past. > VJ> I can ascertain (from AMD) that we have stated interest in, and are in full support of P4TC. Happy to elaborate more if needed. > VJ> Thanks, Vipin Anjali and Vipin is your support for HW support of P4 or a Linux SW implementation of P4. If its for HW support what drivers would we want to support? Can you describe how to program these devices? <VJ2> Both, Sw implementation of P4 would allow prototyping and implementing without DPU/IPU hardware. Users have been deploying AMD P4 DPUs since 2019. They user standard (pensando or virtio) driver on the host and on the sideband compile and run/load P4 programs. At the moment there hasn't been any movement on Linux hardware P4 support side as far as I can tell. Yes there are some SDKs and build kits floating around for FPGAs. For example maybe start with what drivers in kernel tree run the DPUs that have this support? I think this would be a productive direction to go if we in fact have hardware support in the works. <VJ2> You guessed it correctly; AMD DPUs have SDK/build-kits to add hardware P4 support. For cloud infrastructure use case this works well, because one needs to expose a simple NIC (vanilla Ethernet NIC) on the host and therefore the users are okay (and prefer) compiling/loading it out-of-band. But P4TC effort, I am hoping can bring P4 to the users wanting to do inline acceleration. If you want a SW implementation in Linux my opinion is still pushing a DSL into the kernel datapath via qdisc/tc is the wrong direction. Mapping P4 onto hardware blocks is fundamentally different architecture from mapping P4 onto general purpose CPU and registers. My opinion -- to handle this you need a per architecture backend/JIT to compile the P4 to native instructions. This will give you the most flexibility to define new constructs, best performance, and lowest overhead runtime. We have a P4 BPF backend already and JITs for most architectures I don't see the need for P4TC in this context. <VJ2> Well, I am not really a linux network or kernel datapath expert. But my hope certainly is that if a use case this succesful (with deployment in production for 4 years) can be mainstreamed with software (and hardware, if available), it could benefit the end users. If the end goal is a hardware offload control plane I'm skeptical we even need something specific just for SW datapath. I would propose a devlink or new infra to program the device directly vs overhead and complexity of abstracting through 'tc'. If you want to emulate your device use BPF or user space datapath. .John
