mbox series

[RFC,0/4] virtio-net: add tx-hash, rx-tstamp, tx-tstamp and tx-time

Message ID 20231218-v6-7-topic-virtio-net-ptp-v1-0-cac92b2d8532@pengutronix.de (mailing list archive)
Headers show
Series virtio-net: add tx-hash, rx-tstamp, tx-tstamp and tx-time | expand

Message

Steffen Trumtrar Dec. 18, 2023, 11:37 a.m. UTC
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@gmail.com
    Subject: [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp,
    tx-tstamp and tx-time
    From: Willem de Bruijn <willemb@google.com>

    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@pengutronix.de>
---
Willem de Bruijn (4):
      virtio-net: support transmit hash report
      virtio-net: support receive timestamp
      virtio-net: support transmit timestamp
      virtio-net: support future packet transmit time

 drivers/net/virtio_net.c        | 211 ++++++++++++++++++++++++++++++++++++++--
 include/uapi/linux/virtio_net.h |  24 ++++-
 2 files changed, 228 insertions(+), 7 deletions(-)
---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20231218-v6-7-topic-virtio-net-ptp-3df023bc4f4d

Best regards,

Comments

Willem de Bruijn Dec. 18, 2023, 4:36 p.m. UTC | #1
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@gmail.com
>     Subject: [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp,
>     tx-tstamp and tx-time
>     From: Willem de Bruijn <willemb@google.com>
> 
>     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@pengutronix.de>

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. For virtio, perhaps
assuming the same monotonic hardware clock in guest and host can be
assumed. But this clock alignment needs some thought.
Jason Wang Dec. 20, 2023, 3:48 a.m. UTC | #2
On Tue, Dec 19, 2023 at 12:36 AM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> 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@gmail.com
> >     Subject: [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp,
> >     tx-tstamp and tx-time
> >     From: Willem de Bruijn <willemb@google.com>
> >
> >     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@pengutronix.de>
>
> 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
Willem de Bruijn Dec. 20, 2023, 4:25 a.m. UTC | #3
Jason Wang wrote:
> On Tue, Dec 19, 2023 at 12:36 AM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> 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@gmail.com
> > >     Subject: [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp,
> > >     tx-tstamp and tx-time
> > >     From: Willem de Bruijn <willemb@google.com>
> > >
> > >     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@pengutronix.de>
> >
> > 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.

I meant that we cannot assume a specific clock, if aiming to offload
existing pacing (or "launch time") methods.

The issue discussed in the AF_XDP thread is whether to use CLOCK_TAI
or CLOCK_MONOTONIC. Both of which are already in use in software
pacing offload, in the ETF and FQ qdiscs, respectively.

But for virtio it may be acceptable to restrict to one clock, such as
CLOCK_REALTIME or CLOCK_TAI.

CLOCK_MONOTONIC being boottime is almost certain to have an offset.
Even if the clocks' rates are synchronized with phc2sys.

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