p4-dev@lists.p4.org

list for questions/discussion of p4 programs and tools

View all threads

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

AF
Andy Fingerhut
Thu, Dec 23, 2021 5:32 PM

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.

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.
GV
Gurevich, Vladimir
Thu, Dec 23, 2021 6:38 PM

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)http://intel.com/programmable-networking
Director, Intel® Connectivity Education Hubhttp://intel.com/connectivity-education

Email:      Vladimir.Gurevich@intel.commailto:Vladimir.Gurevich@intel.com
Cell:        +1 (408) 833-4505
[A close up of a sign  Description automatically generated]http://intel.com/

From: Andy Fingerhut andy.fingerhut@gmail.com
Date: Thursday, December 23, 2021 at 9:33 AM
To: p4-dev p4-dev@lists.p4.org
Subject: [P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time
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.

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)<http://intel.com/programmable-networking> Director, Intel® Connectivity Education Hub<http://intel.com/connectivity-education> Email: Vladimir.Gurevich@intel.com<mailto:Vladimir.Gurevich@intel.com> Cell: +1 (408) 833-4505 [A close up of a sign Description automatically generated]<http://intel.com/> From: Andy Fingerhut <andy.fingerhut@gmail.com> Date: Thursday, December 23, 2021 at 9:33 AM To: p4-dev <p4-dev@lists.p4.org> Subject: [P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time 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.
AF
Andy Fingerhut
Thu, Dec 23, 2021 7:16 PM

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

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

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)
http://intel.com/programmable-networking
Director, Intel® Connectivity Education Hub
http://intel.com/connectivity-education

Email:      Vladimir.Gurevich@intel.com

Cell:        +1 (408) 833-4505

[image: A close up of a sign Description automatically generated]
http://intel.com/

*From: *Andy Fingerhut andy.fingerhut@gmail.com
*Date: *Thursday, December 23, 2021 at 9:33 AM
*To: *p4-dev p4-dev@lists.p4.org
*Subject: *[P4-dev] Number of top level names in core.p4 and 3 P4
architectures, and change over time

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.

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 On Thu, Dec 23, 2021 at 1:38 PM Gurevich, Vladimir < vladimir.gurevich@intel.com> wrote: > 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) > <http://intel.com/programmable-networking> > Director, Intel® Connectivity Education Hub > <http://intel.com/connectivity-education> > > > > Email: Vladimir.Gurevich@intel.com > > Cell: +1 (408) 833-4505 > > *[image: A close up of a sign Description automatically generated]* > <http://intel.com/> > > > > > > *From: *Andy Fingerhut <andy.fingerhut@gmail.com> > *Date: *Thursday, December 23, 2021 at 9:33 AM > *To: *p4-dev <p4-dev@lists.p4.org> > *Subject: *[P4-dev] Number of top level names in core.p4 and 3 P4 > architectures, and change over time > > 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. >
AF
Andy Fingerhut
Thu, Dec 23, 2021 7:27 PM

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.gurevich@intel.com> wrote:

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)
http://intel.com/programmable-networking
Director, Intel® Connectivity Education Hub
http://intel.com/connectivity-education

Email:      Vladimir.Gurevich@intel.com

Cell:        +1 (408) 833-4505

[image: A close up of a sign Description automatically generated]
http://intel.com/

*From: *Andy Fingerhut andy.fingerhut@gmail.com
*Date: *Thursday, December 23, 2021 at 9:33 AM
*To: *p4-dev p4-dev@lists.p4.org
*Subject: *[P4-dev] Number of top level names in core.p4 and 3 P4
architectures, and change over time

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.

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.gurevich@intel.com> wrote: > 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) > <http://intel.com/programmable-networking> > Director, Intel® Connectivity Education Hub > <http://intel.com/connectivity-education> > > > > Email: Vladimir.Gurevich@intel.com > > Cell: +1 (408) 833-4505 > > *[image: A close up of a sign Description automatically generated]* > <http://intel.com/> > > > > > > *From: *Andy Fingerhut <andy.fingerhut@gmail.com> > *Date: *Thursday, December 23, 2021 at 9:33 AM > *To: *p4-dev <p4-dev@lists.p4.org> > *Subject: *[P4-dev] Number of top level names in core.p4 and 3 P4 > architectures, and change over time > > 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. >
GV
Gurevich, Vladimir
Thu, Dec 23, 2021 10:09 PM

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,
Vladimir Gurevich
Principal Engineer,  Barefoot Division (BXD)http://intel.com/programmable-networking
Director, Intel® Connectivity Education Hubhttp://intel.com/connectivity-education

Email:      Vladimir.Gurevich@intel.commailto:Vladimir.Gurevich@intel.com
Cell:        +1 (408) 833-4505
[A close up of a sign  Description automatically generated]http://intel.com/

From: Andy Fingerhut andy.fingerhut@gmail.com
Date: Thursday, December 23, 2021 at 11:17 AM
To: Gurevich, Vladimir vladimir.gurevich@intel.com
Cc: p4-dev p4-dev@lists.p4.org
Subject: Re: [P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time
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

On Thu, Dec 23, 2021 at 1:38 PM Gurevich, Vladimir <vladimir.gurevich@intel.commailto:vladimir.gurevich@intel.com> wrote:
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)http://intel.com/programmable-networking
Director, Intel® Connectivity Education Hubhttp://intel.com/connectivity-education

Email:      Vladimir.Gurevich@intel.commailto:Vladimir.Gurevich@intel.com
Cell:        +1 (408) 833-4505
[A close up of a sign    Description automatically generated]http://intel.com/

From: Andy Fingerhut <andy.fingerhut@gmail.commailto:andy.fingerhut@gmail.com>
Date: Thursday, December 23, 2021 at 9:33 AM
To: p4-dev <p4-dev@lists.p4.orgmailto:p4-dev@lists.p4.org>
Subject: [P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time
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.

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, Vladimir Gurevich Principal Engineer, Barefoot Division (BXD)<http://intel.com/programmable-networking> Director, Intel® Connectivity Education Hub<http://intel.com/connectivity-education> Email: Vladimir.Gurevich@intel.com<mailto:Vladimir.Gurevich@intel.com> Cell: +1 (408) 833-4505 [A close up of a sign Description automatically generated]<http://intel.com/> From: Andy Fingerhut <andy.fingerhut@gmail.com> Date: Thursday, December 23, 2021 at 11:17 AM To: Gurevich, Vladimir <vladimir.gurevich@intel.com> Cc: p4-dev <p4-dev@lists.p4.org> Subject: Re: [P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time 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 On Thu, Dec 23, 2021 at 1:38 PM Gurevich, Vladimir <vladimir.gurevich@intel.com<mailto:vladimir.gurevich@intel.com>> wrote: 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)<http://intel.com/programmable-networking> Director, Intel® Connectivity Education Hub<http://intel.com/connectivity-education> Email: Vladimir.Gurevich@intel.com<mailto:Vladimir.Gurevich@intel.com> Cell: +1 (408) 833-4505 [A close up of a sign Description automatically generated]<http://intel.com/> From: Andy Fingerhut <andy.fingerhut@gmail.com<mailto:andy.fingerhut@gmail.com>> Date: Thursday, December 23, 2021 at 9:33 AM To: p4-dev <p4-dev@lists.p4.org<mailto:p4-dev@lists.p4.org>> Subject: [P4-dev] Number of top level names in core.p4 and 3 P4 architectures, and change over time 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.