Remove old intrinsic_metadata fields

[jafingerhut]

Removed ucast_egress_port
Only occured in in this one test program: p4_14_samples/sai_p4.p4

Replaced occurrences of ingress_global_tstamp with current
intrinsic_metadata.ingress_global_timestamp

Replaced occurrences of enq_tstamp with current
queueing_metadata.enq_timestamp

Removed occurrences of enq_congest_stat and deq_congest_stat, which
were defined in the two old switch.p4 versions, but never used.

mcast_hash in the two old switch.p4 test programs. There is nothing
in current v1model.p4 to replace them with, but seems best to not
simply delete their few occurrences from switch.p4 source programs.

Deleted occurences of mcast_hash from P4_14 programs that simply
defined it, but never used it.

Deleted all occurrences of intrinsic_metadata struct from P4_16 test
programs that include v1model.p4, since all of those fields are
defined in struct standard_metadata_t now.

[mihaibudiu]

I will approve this, since it is an improvement, but I don't think this solves the problem entirely, it only postpones it. Perhaps we can start with this step, though.

[mihaibudiu]

Do we need this macro?

[jafingerhut]

If I remove that macro and the #ifdef and corresponding #endif, then three of the old intrinsic_metadata fields remain in the post-preprocessed program, and these changes are attempting to prevent that from happening, because simple_switch has no implementation of these fields.

I could delete that code entirely, but the reason I introduced a new macro was because I was thinking that perhaps someone somewhere might want to see the source code that accessed these old fields, and re-enable it.

If folks think that is not going to happen, I could simply delete the few dozen lines of code that are currently between such #ifdef / #endif pairs in the current proposed changes.

[mihaibudiu]

Well, if they are here or in intrinsic_metadata it's rather the same thing; they won't be handled correctly by the compiler if they are expected to have values when the pipeline starts. We still need to move them to stdandard_metadata in v1model.

[jafingerhut]

I agree, but at least this is the name of the metadata "header" that simple_switch documentation has said that these fields must be defined in a P4_14 program for several years now, here: https://github.com/p4lang/behavioral-model/blob/master/docs/simple_switch.md

[jafingerhut]

Also, these fields are initialized by simple_switch today.

EDIT: I mean, they are if they have the expected correct names in the BMv2 JSON file, which they do not today because of the related PR #1704 or something similarly effective goes through, and a similar change is made for queueing_metadata, then simple_switch initializes these fields correctly today.

[mihaibudiu]

Yes, but the way the P4-14 to P4-16 translates this struct will not enable it to use the simple_switch values. We essentially need to put these fields in standard_metadata and make the translator refer to them.

[jafingerhut]

The simple_switch documentation about queueing_metadata is the reason I asked about it in this comment earlier: #1704 (comment)

You replied you had no example programs that used queueing_metadata: #1704 (comment)

I just did some grep'ing through the code and found this test program that uses queueing_metadata, that was committed to the code in 2016 and hasn't been modified since then: https://github.com/p4lang/p4c/blob/master/testdata/p4_14_samples/queueing.p4

Please let me know if there is something you would like changed in this PR, though. I am fine with whatever on this P4_14 intrinsic_metadata and queueing_metadata stuff. It has been documented for years as working this way, then broken some time around Nov 2018. Just looking for a path to getting back to working here.

[jafingerhut]

By the way, if part of the path to getting things working is to change documentation that has been the same for a couple of years, I have no problem with that, either. Just nice if the documentation and implementation are consistent with each other, is all.

[cc10512]

LGTM!