virtio — archive

[PATCH requirements 0/7] virtio net new features requirements

From: Michael S. Tsirkin <[email protected]>
To: [email protected]
Date: Tue, 06 Jun 2023 23:08:00 -0000

On Tue, Jun 06, 2023 at 10:51:25PM +0000, Parav Pandit wrote: > > > > From: Michael S. Tsirkin <[email protected]> > > 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. placing something in a register is a solution. what is the requirement? > > > +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.