You mention a file p4src/includes/intrinsic.p4 that says the units is in nanoseconds. Is this file in some public repository somewhere? Which one? If it is in some switch-ASIC-specific file somewhere, that would not surprise me, e.g. the Tofino ASIC implements units of nanoseconds for similar fields.
Regarding your question “Will the parallel nature of packet processing in P4 switches affect the accuracy of this recorded time?” Unless there is a pretty bad bug in the implementation you are using, I would be very surprised if this is the case. Providing a readable time value in the data plane is a fairly straightforward thing to do.
Warning: In the simple_switch_grpc implementation, the type of ingress/egress_global_timestamp is bit<48>. You are casting these values to bit<64> and then subtracting. It would take about 8.9 years for these bit<48> values to wrap around, but when/if they do, your subtraction will give the wrong result. I would strongly recommend removing the bit<64> casts and keeping the results in type bit<48>. They might not wrap around in a short enough time on simple_switch_grpc for you to ever observe, but in packet processing devices that uses nanoseconds or similar smaller time units for timestamps, they typically wrap around much more often, e.g. every few minutes, and you would see latency calculation bugs quite often.
I would enable logging in simple_switch_grpc using one of these sets of command line options when you start it:
-
--log-console --dump-packet-data 10000 if you want the logging messages to go to the console
-
--log-file ss-log --log-flush --dump-packet-data 10000 if you want logging messages to be written to a file ss-log.txt
You can use the log_msg intrinsic function if you want to cause extra messages to be added to the packet processing log, if the information you would like to see is not already there: p4c/v1model.p4 at main · p4lang/p4c · GitHub
Print out the value of ingress_global_timestamp and egress_global_timestamp before performing the subtraction, and print the result of the subtraction.
In simple_switch_grpc, both of those values should be in units of microseconds. Those values should be 0 at the time you start simple_switch_grpc, and increment once per microsecond after that.
Possible problems I would guess you might be encountering:
The value of ingress_global_timestamp might be 0 if you attempt to read its value in the egress control (I have not verified this, but it seems possible that the implementation only supports a correct value of ingress_global_timestamp in ingress processing). If that is the case, I would recommend declaring a user metadata field with the same type as ingress_global_timestamp, and copying the value of ingress_global_timestamp to that field during ingress processing. Then use that user metadata field, not ingress_global_timestamp, when performing the subtraction during egress processing.