RE: [virtio-comment] Re: [virtio] [PATCH requirements 6/7] net-features: Add packet timestamp requirements

[Parav Pandit <parav@nvidia.com>]

Hi Willem,

> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Sent: Friday, August 11, 2023 2:58 AM
> 
> For synchronization, a single 64-bit MMIO read is not necessarily the fastest
> when traversing real hardware boundaries, or sufficient. PCIe has Precision Time
> Measurement (PTM) hardware logic to capture clock measurement with less
> uncertainty and possibly latency, for instance.
> Indeed, uncertainty is more important than raw latency.
> 
PTM would the next in our line to support on virtio, mainly for the PCIe PFs.

> FWIW, we're also trying to capture similar requires for physical devices through
> the Open Compute Platform NIC Core Offloads effort:
> https://www.opencompute.org/w/index.php?title=Core_Offloads#Timestampin
> g
>
Thanks for the above pointer and your inputs, we are considering many of them in 1.4 timeframe.
Many are post 1.4 so that one can implement also in practical time frame :)
 
> Virtio defines both a virtual interface and one that can be supported by
> hardware, so it's not a 1:1 match, but many subtle points probably apply to
> both.
> 
Yes, it does and the proposal here in first phase is to support both so that precision may not be nsec level but at usec for semi virtual interfaces.
And progress towards supporting PTM after that.

> 
> For timestamping, the difficult part is the transmit completion stamp,
> asynchronous with data flow. If this is taken on the device before or at the time
> of queuing the completion to the host, then it can be stored in\ the completion
> descriptor. 
At this point we are considering before the PHY and after the queuing as listed in this doc.
So that completion can hold this.

> But if taken at the PHY, say, it is not uncommon for this to happen
> after the completion is written. And instead a block of dedicated registers is
> used and the host must poll a register. There are examples of these in the Linux
> device driver directory. For virtio, it is probably sufficient to only support the
> first kind.
> 
We do not have good abstraction of the PHY yet and it is bit hard to adopt to phy when its mix of virtual and physical.
So current plan is to place them in the completions for tx and rx.

> 
> A third aspect is the control path: querying and configuring hardware
> timestamps (siocgstamp/siosgstamp). If hardware is capable, easiest is to just
> timestamp every packet. Much hardware out there targets low rate PTP
> messages. But a virtualized virtio device could timestamp all. In which case this
> control API can maybe be punted on.

Virtualized virtio device will be able to do most of the control and data path timestaping what hw can do.
Likely at lower precision or accuracy... :)