Definition of non-standard P4 constructs in sirius P4 code, and plan for how to run them?

sonic-net / DASH

Disaggregated APIs for SONiC Hosts

Apache License 2.0

86 stars 93 forks source link

Definition of non-standard P4 constructs in sirius P4 code, and plan for how to run them? #12

Open jfingerh opened 2 years ago

jfingerh commented 2 years ago

Examples:

The new match kinds list and range_list
New keywords state_context and state_graph

To my knowledge, these are not supported by the latest open source P4 compiler and behavioral-model / BMv2 software switch.

Is there a plan to release an open source implementation of P4 compiler and BMv2 (or other software switch) that can compile these programs?

Or perhaps to release alternate versions of these P4 programs, perhaps ones mechanically translated from these into P4 that can be compiled and run on an open source P4-programmable software switch?

Or some other plan to enable others to run the reference code, in some way?

jfingerh commented 2 years ago

@marian-pritsak Apologies for the ping, but to call attention to you the questions raised in this issue.

chrispsommers commented 2 years ago

@jfingerh Glad to have you onboard, thanks for filing this. Here are some similar comments I made on the original commit:https://github.com/Azure/DASH/commit/e32f4c23d6691341cb8d623516dc29a6b6257a1c#comments. Note also the P4-16 language spec says new match kinds must be specified in a model file, not "user" code.

jfingerh commented 2 years ago

So my high level comment is: If we want to have a reference model to define the correct behavior of these data plane features, then what will running that reference model require?

only open source code that anyone with a Linux system can compile and execute?
a mix of open source code and proprietary binaries, but those binaries will be made available under a license that anyone can run them at no charge?
requires proprietary binaries with very restrictive and/or requires-paying-money to license?
something else?

For understanding the behavior of the reference model, debugging, etc., the first seems preferable. But perhaps this has already been discussed and I am behind on common understanding among the group here.

chrispsommers commented 2 years ago

Hi Andy, IMO you are posing exactly the right questions at the right time, you're not "behind." More like helping us move forward!

jfingerh commented 2 years ago

Follow up note from the 2021-Dec-08 meeting: Mario Baldi plans to propose changes to the P4 code so that at least the connection tracking part of the code uses the proposed PNA techniques of writing the code, in a near-future pull request.

jfingerh commented 2 years ago

Follow up note from 2021-Jan-05 DASH test group meeting: Marian and/or others from NVIDIA opened up some code that could auto-generate some kind of APIs (SAI perhaps?) from their P4 code that has custom extensions. They also requested help in implementing the behavior for their custom extensions in open source code, e.g. in P4.org's bmv2 project.

KrisNey-MSFT commented 2 years ago

@jfingerh - shall we keep this issue open (based upon the follow-up note)? Or close? TY, Kristina

jfingerh commented 2 years ago

I am fine closing, or leaving open. I guess it depends on whether this issue is tracking the actual completion of an open source runnable reference model, or whether it is tracking "do we know what parts are missing to get there?"