Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making sure that the latest P4Runtime spec is compatible with P4_16 v1.2.4 #448

Closed
jafingerhut opened this issue Aug 15, 2023 · 2 comments
Closed
Labels
p4-language-compatibility An issue related to compatibility between P4_16 language spec and P4Runtime API spec

Comments

@jafingerhut
Copy link
Contributor

There are separate issues for P4Runtime spec compatibility issues with P4_16 language spec versions v1.2.2 and v1.2.3, but I realized today that I don't think I have gone one-by-one through the changes made in v1.2.4 of the language spec. This issue is proposed to record the results of such an investigation, and create separate issues if any potential updates to the P4Runtime API spec are discovered.

@jafingerhut
Copy link
Contributor Author

jafingerhut commented Aug 15, 2023

Abbreviations used here to summarize the effect of the language spec change on P4Runtime API.

  • none-syntax-only - No effect on the P4Runtime API. This is a change in P4_16 language syntax that has no known reason to affect any P4Runtime API messages.
  • none-clarification-only - No effect on the P4Runtime API. This is a clarification or additional restriction on the P4_16 language that has no known reason to affect any P4Runtime API messages.
  • none-concept-only - No effect on the P4Runtime API. This is a change introducing a new concept or category of distinction in the language specification that has no known reason to affect any P4Runtime API messages.
  • maybe-p4runtime-effect - Maybe this should have an effect on the P4Runtime API specification. It seems to warrant a discussion among API work group participants.
  • definitely-p4runtime-effect - Definitely impacts the P4Runtime API specification.

Below is the bullet list of changes from v1.2.3 to v1.2.4 of the P4_16 language specification, copied from here: https://p4.org/p4-spec/docs/P4-16-v1.2.4.html#sec-summary-of-changes-made-in-version-124

  • Added header stack expressions (Section 8.18.1).
    • none-syntax-only
  • Allow casts from a type to itself (Section 8.11).
    • none-syntax-only
  • Added an invalid header or header union expression {#} (Sections 8.17 and 8.19).
    • none-syntax-only
  • Added a concept of numeric values (Section 7.4).
    • none-concept-only
  • Added a section on operations on extern objects (Section 8.22).
    • none-clarification-only
  • Added note in sections operations on types for types that support compile-time size determination.
    • none-clarification-only
  • Clarified that header stacks are arrays of headers or header unions.
    • none-clarification-only
  • Added distinctness of fields for types that have fields including error, match kind, struct, header, and header union.
    • none-clarification-only
  • Clarified types bit, int, and varbit encompass the case where the width is a compile-time known expression evaluating to an appropriate integer (Section 7.1.6.2, Section 7.1.6.3, Section 7.1.6.4).
    • none-clarification-only
  • Clarified restrictions for parameters with default values (Section 6.8.1).
  • Added optional trailing commas (Section 6.4.4).
    • none-syntax-only
  • Clarified the scope of parser namespaces (Section 13.2).
    • none-clarification-only
  • Specified that algorithm for generating control-plane names for keys is optional (Section 18.3.1.3).
    • maybe-p4runtime-effect
  • Clarified types of expressions that may appear in select (Section 13.6).
    • none-clarification-only
  • Added description of semantics of the core.p4 match kinds (Section 14.2.1.1).
    • none-clarification-only
  • Explicitly disallow overloading of parsers, controls, and packages (Section 7.2.10.2).
    • none-clarification-only
  • Clarified implicit casts present in select expressions (Section 13.6).
    • none-clarification-only
  • Clarified that slices can be applied to arbitrary-precision integers (Section 8.8).
    • none-clarification-only
  • Clarified that direct invocation is not possible for objects that have constructor arguments (Section 15.1).
    • none-clarification-only
  • Added comparison for tuples as a legal operation (Section 8.12).
    • none-syntax-only
  • Clarified the behavior of lookahead on header-typed values (Section 13.8.3).
    • none-clarification-only
  • Added static_assert function (Section 19).
    • none-syntax-only
  • Clarified semantics of ranges where the start is bigger than the end (Section 8.15.4).
    • none-clarification-only
  • Allow ranges to be specified by serializable enums (Section 8.15.4).
    • maybe-p4runtime-effect
  • Specified type produced by the sizeInB methods (Section 9).
    • none-clarification-only
  • Added section with operations on match_kind values (Section 8.4).
    • none-clarification-only
  • Renamed infinite-precision integers to arbitrary-precision integers (Section 7.1.6.5).
    • none-clarification-only
  • compiler-inserted default_action is not const (Section 14.2).
    • maybe-p4runtime-effect - worth at least briefly discussing in API work group, but my guess is that this is really just a clarification in the language spec that says explicitly what has already been done for years in the open source P4 implementations.
  • Clarified the restrictions on run time for tables with const entries (Section 14.2.1.4).
    • maybe-p4runtime-effect - I believe this is only a clarification of what existing implementations did, but good to discuss in API work group to make sure.
  • renamed list expressions to tuple expressions
    • none-concept-only
  • Added list type (Section 7.2.7).
    • maybe-p4runtime-effect - If this has an effect on the P4Runtime API spec, I suspect it might only be for the proposed GenericTable additions, which probably already cover all of this and more.
  • Defined entries table property without const, for entries installed when the P4 program is loaded, but the control plane can later change them or add to them (Section 14.2.1.4).
  • Clarified behavior of table with no key property, or if its list of keys is empty (Section 14.2.1.1).
    • maybe-p4runtime-effect - I believe this is only a clarification of what existing implementations did, but good to discuss in API work group to make sure.

@jafingerhut jafingerhut added the p4-language-compatibility An issue related to compatibility between P4_16 language spec and P4Runtime API spec label Aug 15, 2023
@jafingerhut
Copy link
Contributor Author

Closing this issue, as I have created separate issues for the 7 items listed above that might require changes in the P4Runtime API specification, and this issue is no longer needed to track them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p4-language-compatibility An issue related to compatibility between P4_16 language spec and P4Runtime API spec
Projects
None yet
Development

No branches or pull requests

1 participant