Add log_msg extern function to pna.p4 include file?

[jfingerh]

This exists in the v1model.p4 include file, here: https://github.com/p4lang/p4c/blob/main/p4include/v1model.p4#L705-L711

You can find a few examples of its use in this v1model architecture program that runs on BMv2 simple_switch/simple_switch_grpc here: https://github.com/jafingerhut/p4-guide/blob/7b60e42d8aa3e7afe11d630d7f3357bff3064bb9/ptf-tests/registeraccess/registeraccess.p4

Like assert and assume (see #65 ) it is useful for testing and development on software switch environments, and would typically be treated as no-op when compiling to hardware targets.

[jfingerh]

TODO Andy: Discussing this with Cristian Dumitrescu on precisely how these would be implemented on DPDK.

Note that they are already implemented on BMv2 for the v1model architecture. The PSA implementation for BMv2 is only partial as of 2022-Oct, with no one that I know of currently actively working to finish it. Similarly, I do not know of anyone working on BMv2 implementation of PNA architecture at this time.

[jfingerh]

Consider adding log_msg to both PSA and PNA, not only PNA.

[apinski-cavium]

+1 for me.
I might have HW which supports having these log messages out somewhere so it might be useful to mention that like assert it can be turned into a no-op by some mechanism (like you said on real HW it would be a no-op).

[apinski-cavium]

This is more question of how {} are handled, and about the formatting part. Does {0} says the first element of the tuple or is it just {}. How does printing of a header/struct work? For a header, does it print each field and the valid/invalid field. Or is the tuple just supposed to be a tuple of bit/int/bool types (or is bool not supported there).
Or is this just left up to the implementation on what is supported or not supported?
I think defining a standard set of what is the min supported here would be a good idea.

[jfingerh]

I think the BMv2 implementation of this is fairly bare-bones, where each {} in the format string corresponds to the next value to be printed, and there is no variation supported in the format, e.g. no choice of decimal/hex/binary/etc. If you have an Ubuntu system where you are willing to install p4c/behavioral-model/etc. open source dev tools, and write little v1model programs to try out different types of values to log_msg to see what it does today, it shouldn't take long, but I can hack up something over the weekend to show some examples too.

https://github.com/jafingerhut/p4-guide/blob/master/bin/README-install-troubleshooting.md

[jfingerh]

I have updated the comments in the p4c test program issue2201-bmv2.p4 with this PR, so that the comments are up to date with the latest behavioral-model/BMv2 simple_switch behavior of its implementation of the log_msg extern function: p4lang/p4c#3637

Note: There is no spec defining its behavior. It was an implementation created by someone for BMv2, and I'd say does something fairly expedient but useful. I do not know how many people rely on its current precise behavior. I would guess not many, but for all I know someone has created automated test scripts that parse the output of simple_switch to recognize these messages and check their contents :-)