P4 table properties

[jafingerhut]

Should table properties be importable from a namespace?

If so, first they should probably be declarable in some explicit way. There is no such explicit way to declare them defined in the P4_16 language spec that I am aware of. For example, we could say that they should be declared similar to match_kind, perhaps with a syntax like this:

table_properties {
    key,
    actions,
    default_action,
    entries,
    size
}

Then the answers to how they should be named after being imported should hopefully, for consistency's sake, be the same as how they are done for match_kind, however that is (see https://github.com/jafingerhut/p4-namespaces/issues/5)

Table properties defined in the P4_16 language specification include: key, actions, default_action, entries, size (see https://p4.org/p4-spec/docs/P4-16-v1.2.2.html#sec-table-props) Of these properties, size is the one most recently added to the P4_16 language specification. It appears that in the 2021-Dec-31 implementation of p4c, it might be that size is implemented as part of the v1model and PSA architectures, not as part of the standard set of properties. The net effect is probably indistinguishable to P4 developers using p4c, at least with those architectures.

Table properties added in v1model: 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 PSA v1.1: psa_direct_counter, psa_direct_meter, psa_implementation, psa_empty_group_action, psa_idle_timeout (see https://p4.org/p4-spec/docs/PSA-v1.1.0.html#sec-psa-table-properties). 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.

[mihaibudiu]

Indeed, in the languages I can think of only declarations can be imported, so there is nothing you can do about table properties.

[jafingerhut]

This is a design decision. We could choose to say "table properties must be declared before they can be used, and they can be imported between modules/namespaces". I don't understand the viewpoint that this is impossible. It might be undesirable. It might be difficult to implement starting from the implementation we have now. It isn't a fundamental law of the universe that we cannot do anything about it, though.