Support for P4_16 generic types

[jafingerhut]

This issue should be closed exactly when the bullet item “Added support for generic structures” in Section 1.1 "P4 Language Version Applicability" is addressed and removed.

In P4_16 v1.2.2, a feature was introduced where one can declare the following types as generics, i.e. with one or more type parameters:

• struct
• header
• header_union
• header stacks

See examples in Section 7.2.11 titled "Type specialization" in the P4_16 language specification: https://p4.org/p4-spec/docs/P4-16-v-1.2.3.html#sec-type-spec

What should be done in the P4Runtime API specification to support these?

Note: one straightfoward choice is simply to add a brief statement that these generic types are not supported in the P4Runtime API specification. That is, if such types are used in a way that affects the control plane API of a P4 program, then there is no way to use P4Runtime API to configure the P4 objects using those types in their configuration.

Additional notes by Antonin copied from #389 (comment) :

P4Info includes information about structure definitions and maps each structure type by name to its definition. This information is used by P4Runtime when sending a value for that structure type. With support for generic structures, we need to make sure that the generate P4Info is correct, and if necessary update the spec or at least update https://github.com/p4lang/p4runtime/blob/main/docs/v1/guidance-for-generating-p4info.md.

[smolkaj]

Seems easy-enough to say that P4Runtime does not support this at this time. so let's commit at least to that for the release.

[jafingerhut]

Seems fine to me.

Note: If you look at the text of section 1.1 that has a bullet item list of each one of these issues tagged with p4-language-compatibility, it says this before the list:

"This version of the P4Runtime specification does not yet explicitly address compatibility with the following P416 language features introduced in versions 1.2.2 or 1.2.4 of the language specification:"

If you think that wording is clear enough, then I believe all you would need to not support this issue (or the other similarly-tagged ones) in the next release is to just remove the 1.4.0 tag from this issue, and leave the spec as it is now.

[smolkaj]

Good point! Ok