virtio — archive

[Parav Pandit]

> 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.