Making sure that the latest P4Runtime spec is compatible with P4_16 v1.2.2
antoninbas opened this issue · comments
P4Runtime v1.3 recommends using version v1.2.1 of the P4_16 language.
P4_16 v1.2.2 was released in May 2021, with the following changes: https://p4.org/p4-spec/docs/P4-16-v1.2.2.html#sec-summary-of-changes-made-in-version-122. Some of these changes do have an impact on P4Runtime or could have an impact on P4Runtime:
Added support for generic structures: 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.Added support for additional enumeration types: we need to check if there is anything we are not currently covering in P4Info / P4Runtime.Added support for 0-width bitstrings and varbits: not sure if there is any impact for us
So unless I am mistaken, it's primarily 2 items that we have to look into. Would be great to tackle this before the P4Runtime v1.4 release.
That seems reasonable. Agreed it would be nice to upgrade to v1.2.2
@jameschoi I will ping you on several public p4runtime issues to call your attention to them. For others, sorry for the comment noise.
At the moment the latest version is P4_16 v1.2.3, so that should be the new target for P4Runtime v1.4
P4_16 v1.2.4 should come fairly soon, but it is likely to include a significant change (initial entries support) that may have a large impact on P4Runtime. So we probably want to tie P4Runtime v1.4 to P4_16 v1.2.3, and address "initial entries" post v1.4 release.
I have created a separate issues for this new feature mentioned above in Version 1.2.2 of the language spec that might have an impact on the P4Runtime API definition:
- #428 for type
bit<0>values.
It seems like a good idea to create separate issues for each of the other 2 features mentioned above, too, so that each can make progress independently of the others.