Add support for optional action params (with default values if needed) in table entries

[chrispsommers]

Recent work in the SONiC-DASH project indicated the desirability to allow optional action parameters in P4Runtime messages, i.e. a partial number of parameters could be provided by the controller and the backend implementation would handle it appropriately, whether that be supplying [user-specified] default values or some other behavior. Annotations might be one way to indicated optionality and default values on a per-parameter basis.

[smolkaj]

Having optional params with a default value is also something that has come up in the context of PINS.

@zhenk14 for viz

[jafingerhut]

If the default values are run-time configurable, have fun defining read-write symmetry guarantees there :-)

If the default values are constant at run time for a particular P4 program, then it gets easier to do so.

[chrispsommers]

Hi Andy, could you elaborate a bit on the r/w symmetry aspect? Default values would not be constant in general.

[jafingerhut]

Sure, since explaining it in more detail will either make the issue clearer to readers, or it might make it clear to me I'm mistaken in worrying about it.

Consider a single table t1 with one action a1 with one action parameter p1.

If the default value for p1 is configurable at run time, via some new P4Runtime API message yet to be defined, called here SetDefault for the sake of giving it a name, then if there is only one client that has only one outstanding WriteRequest or SetDefault message at a time (never more than one), always waiting for an acknowledgement for each operation before initiating the next, the client can guarantee that all WriteRequest and SetDefault messages must be processed by the server in the order that it sends them to the server.

That seems like a straightforward situation in which you can define preserving read-write symmetry, because the default value for p1 is always from the last SetDefault message sent by the client.

But suppose a single client can send WriteRequest messages concurrently with outstanding SetDefault messages. Then it does not know what order the server will process them in, and cannot then predict what the contents of table entries inserted or modified by its WriteRequest messages will be.

Similarly if there are 2 or more clients concurrently sending such messages to the same server.

[chrispsommers]

There may be some misunderstanding. The intention is to be able to create a table entry with some action parameters (equivalent, in the example mentioned, to SAI attributes) omitted in the update request. The target implementation will provide the missing parameters implicitly. There is no need for a SetDefault message. Does this alter your perception? Admittedly, if such an update is requested, an immediate read back will return additional parameters omitted from the initial request. If this violates the present notion of R/W symmetry, I say it deserves reconsideration.

[jafingerhut]

There are definitely restrictions that could be made on default action parameter values that would make read-write symmetry easy to extend to cover this case, and others where I think it gets trickier. I don't know how whether people want the default action parameter values to be run-time configurable, or decided only at P4-program-compile-time, for example.