On Tue, Dec 19, 2023 at 12:36 AM Willem de Bruijn <willemdebruijn.kernel@xxxxxxxxx> wrote: > > Steffen Trumtrar wrote: > > This series tries to pick up the work on the virtio-net timestamping > > feature from Willem de Bruijn. > > > > Original series > > Message-Id: 20210208185558.995292-1-willemdebruijn.kernel@xxxxxxxxx > > Subject: [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp, > > tx-tstamp and tx-time > > From: Willem de Bruijn <willemb@xxxxxxxxxx> > > > > RFC for four new features to the virtio network device: > > > > 1. pass tx flow state to host, for routing + telemetry > > 2. pass rx tstamp to guest, for better RTT estimation > > 3. pass tx tstamp to guest, idem > > 3. pass tx delivery time to host, for accurate pacing > > > > All would introduce an extension to the virtio spec. > > > > The original series consisted of a hack around the DMA API, which should > > be fixed in this series. > > > > The changes in this series are to the driver side. For the changes to qemu see: > > https://github.com/strumtrar/qemu/tree/v8.1.1/virtio-net-ptp > > > > Currently only virtio-net is supported. The original series used > > vhost-net as backend. However, the path through tun via sendmsg doesn't > > allow us to write data back to the driver side without any hacks. > > Therefore use the way via plain virtio-net without vhost albeit better > > performance. > > > > Signed-off-by: Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> > > Thanks for picking this back up, Steffen. Nice to see that the code still > applies mostly cleanly. > > For context: I dropped the work only because I had no real device > implementation. The referenced patch series to qemu changes that. > > I suppose the main issue is the virtio API changes that this introduces, > which will have to be accepted to the spec. > > One small comment to patch 4: there I just assumed the virtual device > time is CLOCK_TAI. There is a concurrent feature under review for HW > pacing offload with AF_XDP sockets. The clock issue comes up a bit. In > general, for hardware we cannot assume a clock. Any reason for this? E.g some modern NIC have PTP support. > For virtio, perhaps > assuming the same monotonic hardware clock in guest and host can be > assumed. Note that virtio can be implemented in hardware now. So we can assume things like the kvm ptp clock. > But this clock alignment needs some thought. > Thanks
