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

[Parav Pandit <parav@nvidia.com>]

> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Sent: Tuesday, August 15, 2023 8:21 PM
> > 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 :)
> 
> Just be careful about precise use of terminology around this topic:
> uncertainty, precision and the like.
> 
> For example, "a single MMIO read of a 64-bit register gives the lowest latency"
> perhaps can use some clarification.
>
Lower latency compared to accessing it via cvq interface.
 
> In clock synchronization, goal is not to minimize latency of the synchronization
> operation itself, but of the capture of the two timestamps.
> 
Right.
> Which is why PCIe PTM and others use a sandwich of host_ts - device_ts
> - host_ts. The latency between these timestamps is what matters.
> 
Will update to follow this as well. Was hoping to merge with the rtc work ongoing in the virtio to have as part of the net device.

> A single register read is certainly simplest. And it may be correct.
> But be careful if it is strictly worse than returning a pair of timestamps, like
> ptp_clock_info.getcrosststamp. The initial partial implementation should not
> become obsolete as we fill in the details later.
>
I guess it won't be because sandwich mode is still possible with/without mmio.
We can move to read via the queue itself.
 
> > > 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.
> 
> Ack. Sounds good.
> 
> This Tx timestamp is the one where you pointed out that my series was worse
> because "Mainly it incurs yet additional DMA for timestamp that must be
> avoided.", right?
> 
Right.

> >
> > > 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.
> 
> Same as above. Sounds entirely reasonable to me. Just wanted to point out this
> limitation / possible future extension.

True.