P4 table properties

I was looking at the P4 (16) language specification and it only specifies 5 table properties (section 12.2.1) which are key, actions, default_action, entries and implementation. Yet, even in the spec there are references to size and in other documents there are references to counters and meters.
Is there a complete list of the properties somewhere?

size is also defined in the P4_16 language specification document, in the same section that the others are. It is the one most recently added, but it is over a year ago now, and is in the latest released version of the spec.

Those 6 are the only ones required by the base language specification. All others that you have seen are defined either in an architecture like v1model, PSA, TNA, etc., or they are a vendor-specific extension.

Table properties defined by the v1model architecture are: counters , meters , implementation , support_timeout
This appears to be a complete list in the p4c code for all table properties supported by the v1model architecture: https://github.com/p4lang/p4c/blob/main/frontends/p4/fromv1.0/v1model.h#L224-L235

Table properties added by the Portable Switch Architecture (PSA) v1.1: psa_direct_counter , psa_direct_meter , psa_implementation , psa_empty_group_action , psa_idle_timeout (see P4~16~ Portable Switch Architecture (PSA)).
There is no occurrence of the string psa_empty_group_action in the p4c source code as of 2021-Dec-31, so that one is probably not implemented by p4c. The other strings do occur in the p4c source code, but I have not verified whether they are completely implemented by the p4c bmv2 back end, as the PSA bmv2 implementation is only partial as of 2021-Dec-31. The p4c DPDK PSA back end also mentions these properties, except psa_empty_action_group.

I do not have a list of table properties defined by other architectures handy at the moment. I only have these because I recently collected them and recorded them elsewhere.

1 Like

Thank you Andy for a quick reply. So some of the table attributes are architecture dependent (v1model, PSA arch etc…). How is that plays with people who wants to write code that will be architecture independent (which is the promise of P4)?
On a slightly different topic, I see that the parser, control & package types declarations allows the architecture to define the parameters within these types. In this case how would one expect a P4 program on architecture/model X to compile under architecture/model Y? Are there some unwritten expectations that a new architecture should match a basic common structure? For example I see that the v1model ingress control defined as:
control Ingress<H, M>(inout H hdr,
inout M meta,
inout standard_metadata_t standard_metadata);
This enables the developer to define its own header (H) and meta (M) data structures while the architecture defines the standard_metadata.
On the PSA architecture I see a different control defined as:
package IngressPipeline<IH, IM, NM, CI2EM, RESUBM, RECIRCM>(
IngressParser<IH, IM, RESUBM, RECIRCM> ip,
Ingress<IH, IM> ig,
IngressDeparser<IH, IM, CI2EM, RESUBM, NM> id);

Is the expectation is that each architecture will have its own P4 compatible program?

I think you can find some papers that work on multi target program compilation using the same P4 program for different targets and architectures. I cannot remind the paper names, but you can definitely find information about it. Being honest, what P4 promises is Target Independence, not architecture independence (which is also a challenge). That is, the architecture is an abstract model of how the programmable and non-programmable blocks are organized (let’s say a parser, ingress match action units, etc. as defined in the following figure). What I think they mean by Target Independence is that if you program a parser to extract headers, that should be the same P4 code for all devices, no matter the target. The only difference is how the parser is compiled to each target model (which you should not really care about). Targets may implement parsing differently, but a P4 (code) parser should be cross-target compatible unless target-specific things (like externs) are used.

The issue is that you might need to use a functionality (like an extern, which might not be part of the P4 standard code) that is only available for some devices (and thus supported by one or a few targets). Therefore, you could never compile one P4 program for a particular target if the functionality is not supported by that target.

That is how I see it, but anyone more into the topic can put a better perspective into this topic.

Not sure if I understand properly, but if you have a program for the BMv2 Simple switch (V1Model architecture) and you want that same program to compile for another switch (maybe the NetFPGA or Tofino) it will not work without some reformatting. The NetFPGA and the BMv2 simple Switch have different architectures (SimpleSumeSwitch vs V1Model). For instance, the SimpleSumeSwitch has no Ingress and Egress blocks, but just a single one. Therefore, the code for the BMv2 will not compile for the NetFPGA without you formatting the code to fit within 1 control block (blue color), see next Figure:


I am unsure on how to answer this question. But I would say that most architectures should support header parsing and match-action control blocks. It all depends on how that model is associated to your target. I guess that PSA comes as a standard to be used across targets to minimize the issue of using multiple architectures.

I would say that each P4 program, nowadays, is associated to an architecture. But let’s say you want to run your BMv2 Simple Switch (V1Model) program in a target that is associated to the PSA architecture. Then you will have to re-write the code, so it supports new multiple parsers and deparsers. Similarly, each architecture block is probably defined differently, so it also imposes some new changes like control header definition, just like you wrote.

I hope all those more into the language can correct me if I said anything wrong.


I have not checked whether I am repeating what Radostin said in reply to your message, but one thing that I wanted to mention, in case it is not clear because of the name “architecture”, is that a P4 architecture refers to things like “how many parsers, controls, and deparsers are there, if any? How do packets flow between them? What metadata is available about packets at various points? How do I drop a packet, mirror a packet, multicast a packet, if those operations are possible?”

A P4 architecture is NOT a chip specification. The PSA architecture was designed with the intent that multiple switch ASICs could implement that same architecture, and at least for P4 programs that “fit” into the table lookup and packet processing capabilities of multiple such switch ASICs, all of them could compile the same P4 source program, if those device’s P4 compilers supported the PSA architecture.

If that only confuses the issue, please ask, but hopefully it clarifies.

This is a good response :slight_smile:

Andy, your answer makes sense. You also mentioned that the PSA was design with the intent to be the gold standard i.e. it should include the basic elements that are compatible between various architectures.
I am all for it as it will make P4 programs much more compatible. Did I understand you correctly?

“Did I understand you correctly?” It sounds like you did. Note that a device vendor can still choose to make P4-programmable devices that implement other architectures, e.g. ones that start with PSA and add extensions to it. Or they can make architectures that are incompatible with PSA. PSA is offered as a choice to device vendors, but there are certainly other features it does not define that one might want to provide.