Does P4Runtime support struct action parameters?

[qobilidop]

This is a follow-up on p4lang/p4c#3760 (comment) (@jfingerh). I have taken a closer look at the P4Runtime protos, and would like to continue the P4Runtime side of discussion here. I have a feeling struct action parameters are already expressible in P4Runtime, but needs confirmation or correction from P4Runtime experts.

On the P4Info side, there is a type_name for each Param:

p4runtime/proto/p4/config/v1/p4info.proto

Lines 243 to 260 in e70ee7b

	message Action {
	Preamble preamble = 1;
	message Param {
	uint32 id = 1;
	string name = 2;
	repeated string annotations = 3;
	// Optional. If present, the location of `annotations[i]` is given by
	// `annotation_locations[i]`.
	repeated SourceLocation annotation_locations = 8;
	int32 bitwidth = 4;
	// Documentation of the Param
	Documentation doc = 5;
	// unset if not user-defined type
	P4NamedType type_name = 6;
	repeated StructuredAnnotation structured_annotations = 7;
	}
	repeated Param params = 2;
	}

The actual type spec could be looked up in P4TypeInfo:

p4runtime/proto/p4/config/v1/p4types.proto

Lines 55 to 63 in e70ee7b

	message P4TypeInfo {
	map<string, P4StructTypeSpec> structs = 1;
	map<string, P4HeaderTypeSpec> headers = 2;
	map<string, P4HeaderUnionTypeSpec> header_unions = 3;
	map<string, P4EnumTypeSpec> enums = 4;
	P4ErrorTypeSpec error = 5;
	map<string, P4SerializableEnumTypeSpec> serializable_enums = 6;
	map<string, P4NewTypeSpec> new_types = 7;
	}

p4runtime/proto/p4/config/v1/p4types.proto

Lines 83 to 85 in e70ee7b

	message P4NamedType {
	string name = 1;
	}

So in principle, the P4Info file could express a struct action parameter, right?

On the P4Runtime service side, action parameters are specified as flat bytes:

p4runtime/proto/p4/v1/p4runtime.proto

Lines 266 to 273 in e70ee7b

	message Action {
	uint32 action_id = 1;
	message Param {
	uint32 param_id = 2;
	bytes value = 3;
	}
	repeated Param params = 4;
	}

A user-defined struct could easily be flattened as bytes. So I think there is no issue either?

[jfingerh]

For another point of reference, please see section 21 "Known Limitations of Current P4Runtime Version" https://p4.org/p4-spec/docs/p4runtime-spec-working-draft-html-version.html#sec-known-limitations-of-current-p4runtime-version
of the latest P4Runtime specification document, where it says:

FieldMatch, action Param, and controller packet metadata fields only support unsigned bitstrings, i.e. values of one of the following types (not the more general P4Data):

bit<W>
bool. Note that as far as the P4Info message contents and thus controller software is concerned, such fields of type bool will be indistinguishable from those that have been declared with type bit<1>. P4Runtime server software will automatically perform any conversion needed between the type bit<1> values in P4Runtime messages and the data plane representation.
an enum with underlying type bit<W>
a type or typedef with an underlying type that is one of the above (or in general a “chain” of type and/or typedef that eventually ends with one of the types above)

If that part of the spec is obsolete, it should be removed.

[qobilidop]

I see. I didn't notice that part of the spec previously!

Then my understanding is that syntactically, any type_name could be used for an action param. But semantically, there are further restrictions. Currently type_name is there only to support type/typedefs that could be reduced to the basic types mentioned above.

[jfingerh]

That is also my understanding, yes. Also, even if the Protobuf definitions might not require any changes to become more general in types of action parameters that are supported, P4Runtime client and server implementations certainly would need updating to support more types, as I suspect that most or all of them have been developed with that type restriction in mind.

[jafingerhut]

@qobilidop Note that the work on GenericTable in the API work group the last couple of months is intended to enable generalizing key and action parameter types to structs, and many other more general things. That work is still in progress, not yet implemented in open source as of 2023-Aug, etc. but you may want to keep track of it at least occasionally.