Is this the intended effect of `@name` annotations when generating P4Info files?

[jafingerhut]

I was inspired by a recent issue asking about compiler internal passes renaming action parameters (or not) to find out what the P4Info file generated contains when @name annotations are used on (directionless) action parameters, and several other language constructs, including tables, table key fields, table action names in the actions list, an action definition itself, and a control definition.

The attached program name_annotations_to_p4info.p4.txt is a v1model architecture P4_16 program, and name_annotations_to_p4info.p4.p4info.txt is the P4Info file generated via the following command:

$ p4c --version
p4c 1.2.0 (SHA: e3f36f6d9 BUILD: DEBUG)

$ p4c --target bmv2 --arch v1model --p4runtime-files name_annotations_to_p4info.p4.p4info.txt name_annotations_to_p4info.p4

@antoninbas @vgurevich (and anyone else interested) Looking at the generated P4Info file, are these the names you would expect the control plane API to see from this P4 source program?

name_annotations_to_p4info.p4.txt

name_annotations_to_p4info.p4.p4info.txt

[antoninbas]

Yes, this is more or less the P4Info I would expect. But my P4 is a bit rusty...

• IngressI is used to prefix all objects defined in the IngressI control block. The way I see it is that when you instantiate the V1Switch package, you instantiate an anonymous instance of IngressI(), while @name("altIngressName") is an annotation on the type. I don't remember if the following syntax is valid, but this would be my first instinct as to the "right" syntax if you want to introduce a new name for the instance:

  V1Switch(ParserI(), VerifyChecksumI(), @name("newName") IngressI(), EgressI(),
       ComputeChecksumI(), DeparserI()) main;

  Now one could argue that we should still use the annotation on the control block if that's all we have, and I would be fine with that. Another valid option would be to use the parameter name, which is ig in this case (actually this is what I would have guessed we were doing before looking at your example).

• The annotations on the action references in the table declaration are ignored. I would say this is a limitation of the ActionRef message in P4Info which should probably include a name field. The logic for having a dedicated ActionRef message was to be able to accommodate for something like the code below (again not sure if this is currently legal P4). I think this is a change we should consider making in P4Info.

  table t {
  actions = {
     @name("foo") a(5);
     @name("bar") a(9);
  }
  }

Besides these 2 points, I don't think anything else is contentious. The @name annotations are handled as they should for match fields, action parameters, actions, tables, etc.

[antoninbas]

I feel like an update to https://github.com/p4lang/p4runtime/blob/main/docs/v1/guidance-for-generating-p4info.md is coming :)