OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]