[<prev] [next>] [day] [month] [year] [list]
Message-ID:
<MW4PR12MB7192E0AC231E37EE6224319C97F22@MW4PR12MB7192.namprd12.prod.outlook.com>
Date: Wed, 29 May 2024 01:44:07 +0000
From: "Jain, Vipin" <Vipin.Jain@....com>
To: John Fastabend <john.fastabend@...il.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
[Public]
Inline as <VJ2>... (was html, sorry)
________________________________________
From: John Fastabend <john.fastabend@...il.com>
Sent: Tuesday, May 28, 2024 1:17 PM
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
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@....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?
<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
Powered by blists - more mailing lists