Bring up transmission timestamp of packets to P4

[nhnghia]

I'm trying to bring transmission timestamp of a packet up to P4 program.

I see that I can override bmi_interface_send to get the tx timestamp. It is not a big deal as I can access to its raw socket descriptor, then by setting SO_TIMESTAMPING option to the socket I can get tx timestamp.

I was wondering whether there exists a simple way to bring this tx timestamp up to the P4 program (this timestamp will be used by the next iteration, e.g., when the P4 program processes the next packet).

Thanks in advance for any suggestion!

[jafingerhut]

There is a C++ method named get_ts in this file: https://github.com/p4lang/behavioral-model/blob/main/targets/simple_switch/simple_switch.cpp#L399

If you look in that same file for where it is called, it is used to fill in the values of metadata fields ingress_global_timestamp and egress_global_timestamp, by reading the time just before ingress/egress processing begins. In the v1model architecture, those values are available as fields in the standard_metadata struct, readable by the P4 code you write by those names.

Thus if you change only the definition of method get_ts, it will change the values filled into those metadata fields. Right now it is defined to be the number of microseconds since the simple_switch process started.

[nhnghia]

Thanks @jafingerhut , I saw ingress_global_timestamp and egress_global_timestamp.

These values miss some delays when measuring the time a packet is taken when it goes through from an ingress port to an egress port of a BMv2 switch.

For example, egress_global_timestamp represents the moment when the packet is started processing by the P4 egress pipeline. It does not reflex the moment, saying egress_mac_global_timestamp, the packet is sent out by the egress port which is a virtual or physical NIC. Thus egress_mac_global_timestamp must not be available on the P4 processing of the current packet.

[jafingerhut]

You are correct that ingress/egress_global_timestamp are read shortly before the current packet begins its ingress/egress processing.

It sounds like during egress processing, you want a packet to be able to read the time that the previous packet going to the same output port was transmitted?

And I guess you want to maintain this value independently for each port of the switch? If you want it globally for the whole device, that may be slightly easier to implement in BMv2, but it sounds like something that I have no idea what you would use it for, if it were the last time a packet was transmitted on any port.

I have not added such a feature to BMv2 before, but one way would be to add a new object that looks like a P4 register array, with one element per port, indexed by the port number, where the value was the last time a packet was transmitted on that port. If you restrict yourself in the P4 program to never writing it, and only reading the entry that corresponds to the packet's destination port in standard_metadata.egress_port, that might behave the way you hope?

Note that for a very high speed P4-programmable device, there might be multiple packets being processed in a pipeline simultaneously, all going to the same output port. Trying to implement something like this in such a device would either (a) prevent that pipelining, or (b) read the time that a packet 2 or 3 packets before went to the port, not the previous one.

[nhnghia]

Thanks @jafingerhut for detailed suggestion! I will looking into the way the register being implemented.

Otherwise, to improve the performance I'm thinking about something like capture_tstamp_on_tx in tofino. This value is required to be enabled in P4 to explicitly indicate whether the tx timestamp of the outgoing packet will be available in the next round.