Add ability to specify preferred string representation of types

[chrispsommers]

It'd be handy to be able to specify, in one place, the preferred string representation of selected data types, e.g. IPv4 should be represented as dotted-decimal, etc. Use-cases would be to enable P4Runtime clients (CLIs, GUIs) and even server-side debug logs to format data in the appropriate human-readable format. Various ad hoc techniques are already solving this problem one way or another (custom annotations in P4 code; annotation APIs in vendor runtime libraries; etc.). A standardized way of solving this would be very useful. The oft-heard response to this perennial issue has been "use an annotation," so we might as well begin defining some standardized ones and present to the LDWG as a proposal for a new reserved annotation.

I hereby propose to:

• define a new reserved annotation, e.g. @repr(format) in the P4-16 language spec. I chose this based on the familiar Python __repr__ attribute (plus it's short). it can be anything we like but it should be concise!
• format can be one of:
  • ipv4 - IPv4 dotted decimal, e.g. 192.168.1.1
  • ipv6 - IPv6 quad notation e.g. 1234:5678::abcd
  • cidr - Ternary/LPM value as an IP Prefix e.g. 192.168.1.0/24 or 2001:db8::/48 auto-selected based on size (32 bits or 128 bits)
  • mac - MAC address, e.g. 01:23:45:67:89:ab
  • dec - decimal e.g.4095
  • hex - hexadecimal e.g. 0xdeadbeef
  • bin - binary e.g. 01011010
  • bool - boolean, e.g. true
  • ascii - ASCII text, e.g. Hello

These annotations would appear in P4Info and can be consumed by clients as well as servers to use or not at their discretion. The only impact of this proposal would be to reserve and document a new annotation in the P4-16 language spec.

[jafingerhut]

A little bit of semi-related history here.

The type keyword and the @p4runtime_translation annotation were created as one way to associate annotations about user-defined type names with things like this. Unfortunately it only works for user-defined types defined with type. The disadvantage of those is that some people find it inconvenient that they must use casts in P4_16 in order to assign values between different type, or between bit<32> and a type defined as type bit<32> IPv4Address;. If you like having to write casts for different user-defined types, then you should take a look at @p4runtime_translation and see if it answers this question for you, or whether by adding a few commonly-used standard @p4runtime_translation annotation, it resolves this issue for you.

It might be possible to modify open source p4c so that we can put an annotation like @p4runtime_translation on a typedef definition, and this annotation is automatically associated with all fields, action parameters, etc. that are declared with that typedef name, similarly to how type works today. I asked a question about this in 2020 here p4lang/p4c#2310 and Mihai Budiu gave some code snippets that he believed would be able to do this, but I am not knowledgeable enough about p4c internals to figure out how to make it work from that. If someone else is, or you can find someone who is and persuade them to work on that code, I think it could be useful in achieving the goal of this issue.

[jafingerhut]

By the way, if anyone has not tried defining a type in their P4_16 program and using a @p4runtime_translation annotation on it, I would encourage them to do at least a little bit of experimenting with it, and give feedback on (a) what they like about it, and (b) what they wish were different. I can try designing "something different", but specific suggestions of what is missing from the current implementation of those features would help in guiding what the "something different" ought to look like.

[jafingerhut]

Note: Chris, your initial comment is good, but one of my main questions for ergonomics of such a feature is "where would you expect to have to write the @REPR annotation in your P4_16 source code". If you are happy adding @repr("ipv4") to every action parameter and header field and metadata variable that is type bit<32>, then I would recommend actually trying it out in some P4_16 program you have in mind and see how many occurrences of that you would need to add, vs. if there were a type that. you could add it once, then use that type consistently on all values currently defined as bit<32>.

If you want @repr("ipv4") on a typedef to avoid the need to write so many casts in assignments between values with different type named types, then my first comment on this issue is very relevant, and I'd like it if someone who knew the p4c compiler internals at least a little bit coud look into it.