From c8c84f48eab26e69fa57d418cd9526dcdbb6bbe8 Mon Sep 17 00:00:00 2001 From: Antonin Bas Date: Thu, 28 Nov 2019 17:57:28 -0800 Subject: [PATCH] Use 1.1 / 1.1.0 when referring to the current P4Runtime version --- docs/v1/P4Runtime-Spec.mdk | 2 +- docs/v1/guidance-for-generating-p4info.md | 12 ++++++------ 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/v1/P4Runtime-Spec.mdk b/docs/v1/P4Runtime-Spec.mdk index 05b0dfc5..3ba5367a 100644 --- a/docs/v1/P4Runtime-Spec.mdk +++ b/docs/v1/P4Runtime-Spec.mdk @@ -5613,7 +5613,7 @@ field [@ProtoAny]. At the moment, there is not any mechanism to extend the `p4.v1.TableEntry` message based on the value of architecture-specific table properties, but we may include on in future versions of the API. -# Known limitations of P4Runtime v1.0.0 +# Known Limitations of Current P4Runtime Version * `FieldMatch`, action `Param`, and controller packet metadata fields only support unsigned bitstrings, &ie; values of one of the following types (not diff --git a/docs/v1/guidance-for-generating-p4info.md b/docs/v1/guidance-for-generating-p4info.md index 580549a4..1ddb1255 100644 --- a/docs/v1/guidance-for-generating-p4info.md +++ b/docs/v1/guidance-for-generating-p4info.md @@ -38,7 +38,7 @@ representing the name of the library, its major version, etc. ## Handling P4_16 `type` and the `p4runtime_translation` annotation -The P4Runtime v1.0 specification restricts the types that it supports +The P4Runtime v1.1 specification restricts the types that it supports for the following kinds of things: + table search key fields, defined in the P4Info message in a @@ -50,17 +50,17 @@ for the following kinds of things: + metadata fields in a header sent from data plane to controller, or from controller to the data plane, defined in the P4Info message in a `Metadata` message (the `type_name` field was added to `Metadata` - messages in P4Runtime version 1.0.1). + messages in P4Runtime version 1.1.0). Later in this section, we will use the term "constrained value" for brevity, instead of repeating all of the kinds of objects listed -above. For such values, the P4Runtime specification v1.0 supports all +above. For such values, the P4Runtime specification v1.1 supports all of the following types, but currently no others: + `bit` + an `enum` with an underlying type of `bit`, also called a serializable `enum` (TBD whether all of the pieces needed to make - this work are actually supported for P4Runtime 1.0) + this work are actually supported for P4Runtime 1.1) + a `typedef` or `type` name that, when "followed back" to the lowest base type, is one of the above. (As of the P4_16 language specification version 1.2.0, it is not required to support a `type` @@ -100,7 +100,7 @@ type_list(x) { Note that `type_list(x)` always starts with zero or more `type` names, and always ends with one type that is neither a `type` nor `typedef` name, e.g. `bit`, a header type, struct type, etc. It never -contains the name of a type declared using `typedef`. P4Runtime v1.0 +contains the name of a type declared using `typedef`. P4Runtime v1.1 only supports `p4runtime_translation` annotations on `type` definitions. If any such annotations occur on a `typedef` definition, they should be ignored. @@ -111,7 +111,7 @@ of type names. In order to create such a cycle, the first `type` or type name, and this is not allowed. If the last type is not `bit` or `enum bit`, that is an error -for P4Runtime v1.0. The "base" type must always be one of those for +for P4Runtime v1.1. The "base" type must always be one of those for every constrained value.