Tom Herbert wrote: > On Tue, Jun 11, 2024 at 8:53 AM Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote: > > > > On Tue, Jun 11, 2024 at 11:33 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > > > > > On Tue, 11 Jun 2024 11:10:35 -0400 Jamal Hadi Salim wrote: > > > > > Before the tin foil hats gather - we have no use for any of this at > > > > > Meta, I'm not trying to twist the design to fit the use cases of big > > > > > bad hyperscalers. > > > > > > > > The scope is much bigger than just parsers though, it is about P4 in > > > > which the parser is but one object. > > > > > > For me it's very much not "about P4". I don't care what DSL user prefers > > > and whether the device the offloads targets is built by a P4 vendor. > > > > > > > I think it is an important detail though. > > You wouldnt say PSP shouldnt start small by first taking care of TLS > > or IPSec because it is not the target. > > > > > > Limiting what we can do just to fit a narrow definition of "offload" > > > > is not the right direction. > > Jamal, > > I think you might be missing Jakub's point. His plan wouldn't narrow > the definition of "offload", but actually would increase applicability > and use cases of offload. The best way to do an offload is allow > flexibility on both sides of the equation: Let the user write their > data path code in whatever language they want, and allow them offload > to arbitrary software or programmable hardware targets. +1. > > For example, if a user already has P4 hardware for their high end > server then by all means they should write their datapath in P4. But, > there might also be a user that wants to offload TCP keepalive to a > lower powered CPU on a Smartphone; in this case a simple C program > maybe running in eBPF on the CPU should do the trick-- forcing them to > write their program in P4 or even worse force them to put P4 hardware > into their smartphone is not good. We should be able to define a > common offload infrastructure to be both language and target agnostic > that would handle both these use cases of offload and everything in > between. P4 could certainly be one option for both programming > language and offload target, but it shouldn't be the only option. Agree major benefit of proposal here is it doesn't dictate the language. My DSL preference is P4 but no need to push that here. > > Tom My $.02 Jakub's proposal is a very pragmatic way to get support for P4 enabled hardware I'm all for it. I can't actually think up anything in the P4 hardware side that couldn't go through the table notion in (7). We might want bulk updates and the likes at some point, but starting with basics should be good enough. > > > > > > > This is how Linux development works. You implement small, useful slice > > > which helps the overall project. Then you implement the next, and > > > another. +1. > > > > > > On the technical level, putting the code into devlink rather than TC > > > does not impose any meaningful limitations. But I really don't want > > > you to lift and shift the entire pile of code at once. > > > devlink or an improved n_tuple (n_table?) mechanism would be great. Happy to help here. > > > > Yes, the binary blob is going via devlink or some other scheme. > > > > > > P4 is well understood, hardware exists for P4 and is used to specify > > > > hardware specs and is deployed(See Vipin's comment). > > > > > > "Hardware exists for P4" is about as meaningful as "hardware exists > > > for C++". > > > > We'll have to agree to disagree. Take a look at this for example. > > https://www.servethehome.com/pensando-distributed-services-architecture-smartnic/ > > > > cheers, > > jamal >
