Date: Tue, 28 May 2024 13:17:12 -0700
From: John Fastabend <john.fastabend@...il.com>
To: "Jain, Vipin" <Vipin.Jain@....com>, 
 "Singhai, Anjali" <anjali.singhai@...el.com>, 
 "Hadi Salim, Jamal" <jhs@...atatu.com>, 
 Jakub Kicinski <kuba@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>, 
 Alexei Starovoitov <alexei.starovoitov@...il.com>, 
 Network Development <netdev@...r.kernel.org>, 
 "Chatterjee, Deb" <deb.chatterjee@...el.com>, 
 "Limaye, Namrata" <namrata.limaye@...el.com>, 
 tom Herbert <tom@...anda.io>, 
 Marcelo Ricardo Leitner <mleitner@...hat.com>, 
 "Shirshyad, Mahesh" <Mahesh.Shirshyad@....com>, 
 "Osinski, Tomasz" <tomasz.osinski@...el.com>, 
 Jiri Pirko <jiri@...nulli.us>, 
 Cong Wang <xiyou.wangcong@...il.com>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Vlad Buslov <vladbu@...dia.com>, 
 Simon Horman <horms@...nel.org>, 
 Khalid Manaa <khalidm@...dia.com>, 
 Toke Høiland-Jørgensen <toke@...hat.com>, 
 Victor Nogueira <victor@...atatu.com>, 
 "Tammela, Pedro" <pctammela@...atatu.com>, 
 "Daly, Dan" <dan.daly@...el.com>, 
 Andy Fingerhut <andy.fingerhut@...il.com>, 
 "Sommers, Chris" <chris.sommers@...sight.com>, 
 Matty Kadosh <mattyk@...dia.com>, 
 bpf <bpf@...r.kernel.org>, 
 "lwn@....net" <lwn@....net>
Subject: Re: On the NACKs on P4TC patches

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@....com>
> Sent: Friday, May 24, 2024 2:28 PM
> To: Singhai, Anjali <anjali.singhai@...el.com>; Hadi Salim, Jamal <jhs@...atatu.com>; Jakub Kicinski <kuba@...nel.org>
> Cc: Paolo Abeni <pabeni@...hat.com>; Alexei Starovoitov <alexei.starovoitov@...il.com>; Network Development <netdev@...r.kernel.org>; Chatterjee, Deb <deb.chatterjee@...el.com>; Limaye, Namrata <namrata.limaye@...el.com>; tom Herbert <tom@...anda.io>; Marcelo Ricardo Leitner <mleitner@...hat.com>; Shirshyad, Mahesh <Mahesh.Shirshyad@....com>; Osinski, Tomasz <tomasz.osinski@...el.com>; Jiri Pirko <jiri@...nulli.us>; Cong Wang <xiyou.wangcong@...il.com>; David S. Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Vlad Buslov <vladbu@...dia.com>; Simon Horman <horms@...nel.org>; Khalid Manaa <khalidm@...dia.com>; Toke Høiland-Jørgensen <toke@...hat.com>; Victor Nogueira <victor@...atatu.com>; Tammela, Pedro <pctammela@...atatu.com>; Daly, Dan <dan.daly@...el.com>; Andy Fingerhut <andy.fingerhut@...il.com>; Sommers, Chris <chris.sommers@...sight.com>; Matty Kadosh <mattyk@...dia.com>; bpf <bpf@...r.kernel.org>; lwn@....net <lwn@....net>
> 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@...el.com>
> Sent: Wednesday, May 22, 2024 5:30 PM
> To: Hadi Salim, Jamal <jhs@...atatu.com>; Jakub Kicinski <kuba@...nel.org>
> Cc: Paolo Abeni <pabeni@...hat.com>; Alexei Starovoitov <alexei.starovoitov@...il.com>; Network Development <netdev@...r.kernel.org>; Chatterjee, Deb <deb.chatterjee@...el.com>; Limaye, Namrata <namrata.limaye@...el.com>; tom Herbert <tom@...anda.io>; Marcelo Ricardo Leitner <mleitner@...hat.com>; Shirshyad, Mahesh <Mahesh.Shirshyad@....com>; Osinski, Tomasz <tomasz.osinski@...el.com>; Jiri Pirko <jiri@...nulli.us>; Cong Wang <xiyou.wangcong@...il.com>; David S. Miller <davem@...emloft.net>; Eric Dumazet <edumazet@...gle.com>; Vlad Buslov <vladbu@...dia.com>; Simon Horman <horms@...nel.org>; Khalid Manaa <khalidm@...dia.com>; Toke Høiland-Jørgensen <toke@...hat.com>; Victor Nogueira <victor@...atatu.com>; Tammela, Pedro <pctammela@...atatu.com>; Jain, Vipin <Vipin.Jain@....com>; Daly, Dan <dan.daly@...el.com>; Andy Fingerhut <andy.fingerhut@...il.com>; Sommers, Chris <chris.sommers@...sight.com>; Matty Kadosh <mattyk@...dia.com>; bpf <bpf@...r.kernel.org>; lwn@....net <lwn@....net>
> 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@...nel.org> 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@...atatu.com > 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@IA0PR17MB7070.namprd17.prod.outlook.com/
> 
> 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?

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.

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.

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

Powered by blists - more mailing lists