[P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time

[Andy Fingerhut]

As part of working through ideas for a design of a P4 namespace system [1], I was curious how many "top level names" are defined in each of these include files: core.p4, v1model.p4, psa.p4, and tna.p4.

The files are all in this directory of my p4-guide repo: https://github.com/jafingerhut/p4-guide/tree/master/namespaces

Here is a quick count of top level names defined in the latest version of each file.  See the files for some details of how that set of names has changed over time.

core.p4 - only 4!

v1model.p4 - 41

psa.p4 - 93

tna.p4 - 86

Note: these counts do not include match_kind and error definitions.  I have left those out of these counts since it isn't clear to me yet whether they are best considered as separate top level names, or basically all "scoped" inside of the "match_kind { ... }" and "error { ...}" scopes.

In case this is not familiar to everyone, core.p4 is a file containing definitions that are intended to be part of all P4_16 implementations, regardless of what architecture they implement.  All of its (few) definitions are described in the P4_16 langauge specification document.

The other three are 3 examples of P4_16 architectures.  v1model was originally created to be a target for automatic translation of P4_14 programs to P4_16 programs.  PSA v1.0 was first published in 2018, intended to be an architecture that multiple P4-programmable switch ASIC vendors might implement, at least as a common base set of features that they might then extend with their own extras.  TNA is the Tofino Native Architecture for the Tofino1 switch ASIC.

There are other P4_16 architectures that I have not done this analysis for.  What I have done only takes a little bit of time for a P4 include file like these, except for the part where I went back through the public git commit history to see how things changed over time.  That can take a bit longer.  There probably are not very many people curious about that history of change, but if you are one of those few, Merry Christmas!

Regards,

Andy Fingerhut

[1] https://docs.google.com/document/d/1NNC4t5NjAhzOhiC_DauiYrw80h1cXjZhshdRTuAPSnc

I will send out invites to a (short) series of public P4.org meetings whose purpose is solely to discuss details of this P4 namespace proposal, with the goal of answering open questions and writing a proposed spec for this feature, to be considered for addition to a future version of the P4_16 language specification.

[Gurevich, Vladimir]

Hi Andy,

 

For the problem statement point of view, I would consider anything that doesn�t have a prefix to be a top-level name.

 

Given that match_kind and error values are not prefixed (unlike enum values), I think we should consider them top-level names. Similarly, we have standard methods/fields (i.e. �hit�, �miss�, �action_run�, �last�, �next�, �push_front�, �minSizeInBits�, etc.) that I would also point out.

 

The reason is that all these regularly come up during our discussions on backward/forward compatibility and your proposal touches upon the same topics. I am not saying that we should necessarily try to fix everything with it, but I think it might be a worthy consideration. For example, we can define a reserved namespace (e.g. P4) and put all these in there and then allow these to be imported by default of something.

 

Best,

Vladimir Gurevich

Principal Engineer,  Barefoot Division (BXD)
Director, Intel� Connectivity Education Hub

 

Email:      Vladimir...@intel.com  

Cell:         +1 (408) 833-4505

[Andy Fingerhut]

Vlad:

With the current P4 namespace proposal I am editing that document for, methods of extern objects are NOT top level names.  The name of the extern object is a top level name.

Why do I think it is a nice thing if method names are NOT considered top-level?  Mainly because it simplifies the problem of designing a P4 namespace system.  But if you have alternatives that make extern object method names count as top level names, please write up a description and some examples, and we can all try to poke holes in it.

Another reason: Everywhere that one can do a method call in a P4 program, there must be an instance of that object just before it, e.g. hdr.foo.isValid().  You cannot write isValid() by itself, without an instance of some appropriate type of object just before it.  Thus the compiler already has a quite narrow scope of legal names to look up method names, that I consider NOT top level in scope.

If one takes this view, method names, including the ones that don't have parentheses in the P4_16 language spec (I will call action_run and similar things an "attribute" for the purposes of calling those kinds of things something other than methods, which they currently aren't), including all of those listed below, can only collide with other names/attributes _of the same kind of extern object_, but not with other top level names.

"hit”, “miss”, “action_run”, “last”, “next”, “push_front”, “minSizeInBits”

Regards,

Andy

[Andy Fingerhut]

Also error in the current P4_16 language spec MUST always be prefixed with "error." when you name them.  That could change, of course, but I don't see any benefit to making such a change.

The question about "error" is part of that monster 22-page doc I'm writing.  Also questions about match_kind.  And lots of other details.  Sure, not fun to read, but I thought about many such details already and tried to at least raise the questions in the design doc.  Maybe not to everyone's satisfaction -- that is the purpose of the review.  Reviewing this proposal is a job that probably requires multiple hours of time, even for P4 language experts.  I encourage you to read and think about everything in the document, and see what is missing, or answered poorly, or is still open.

Andy

On Thu, Dec 23, 2021 at 1:38 PM Gurevich, Vladimir <vladimir...@intel.com> wrote:

[Gurevich, Vladimir]

Hello Andy,

 

I agree. We can safely exclude methods/fields, defined on the standard objects, since they are always prefixed and there is no way that someone can just add a new method on a header or a table (or even packet_in) without changing the compiler.  

 

So, that leaves us with match_kind (s) and, maybe, table attributes (since each architecture can define its own).

 

Thanks,