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

[Parav Pandit <parav@nvidia.com>]

> From: Michael S. Tsirkin <mst@redhat.com>
> Sent: Tuesday, June 6, 2023 6:40 PM

> > +## 3.5 Packet timestamp
> > +1. Device should provide transmit timestamp and receive timestamp of the
> packets
> > +   at per packet level when the device is enabled.
> > +2. Device should provide the current free running clock in the least latency
> > +   possible using an MMIO register read of 64-bit to have the least jitter.
> 
> wow these reads are expensive. what is the actual requirement?
> 
I don't understand the question.

> > +3. Device should provide the current frequency and the frequency unit for
> the
> > +   software to synchronize the reference point of software and the device
> using
> > +   a control vq command.
> 
> let's leave mechanism out of it. I think you are trying to say this is async to data
> vqs? and cvq is fine.
>
There are two clocks running, one of cpu where driver is running, other one is in the device.
And timestamps are done by the device based on its clock.

So driver can convert the device timestamp to driver cpu timestamp.
This is like one time query to know conversion mechanics.

> > +### 3.5.2 Receive timestamp
> > +1. Receive completion must contain a packet reception timestamp when the
> device
> > +   is enabled for it.
> > +2. The device should record the received packet timestamp at the closet
> ingress
> > +   point of reception from the network.
> > +3. The device should provide a receive packet timestamp in a single DMA
> > +   transaction along with the rest of the receive completion fields.
> 
> how large do these need to be? ok for timer to overflow?
>
Will add it. Usually 8B.
But overflow after 30+ years or so is common norm.

 
> 
> why do you mention migration in counters but not in timers?
> 
> is it ok for time to go back?

Should add it for timer too.