netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>,
	virtualization@lists.linux-foundation.org,
	Network Development <netdev@vger.kernel.org>,
	Richard Cochran <richardcochran@gmail.com>,
	Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH RFC v2 3/4] virtio-net: support transmit timestamp
Date: Tue, 9 Feb 2021 21:36:58 -0500	[thread overview]
Message-ID: <CAF=yD-Lw7LKypTLEfQmcqR9SwcL6f9wH=_yjQdyGak4ORegRug@mail.gmail.com> (raw)
In-Reply-To: <20210209113643-mutt-send-email-mst@kernel.org>

On Tue, Feb 9, 2021 at 11:39 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Tue, Feb 09, 2021 at 01:45:11PM +0800, Jason Wang wrote:
> >
> > On 2021/2/9 上午2:55, Willem de Bruijn wrote:
> > > From: Willem de Bruijn <willemb@google.com>
> > >
> > > Add optional PTP hardware tx timestamp offload for virtio-net.
> > >
> > > Accurate RTT measurement requires timestamps close to the wire.
> > > Introduce virtio feature VIRTIO_NET_F_TX_TSTAMP, the transmit
> > > equivalent to VIRTIO_NET_F_RX_TSTAMP.
> > >
> > > The driver sets VIRTIO_NET_HDR_F_TSTAMP to request a timestamp
> > > returned on completion. If the feature is negotiated, the device
> > > either places the timestamp or clears the feature bit.
> > >
> > > The timestamp straddles (virtual) hardware domains. Like PTP, use
> > > international atomic time (CLOCK_TAI) as global clock base. The driver
> > > must sync with the device, e.g., through kvm-clock.
> > >
> > > Modify can_push to ensure that on tx completion the header, and thus
> > > timestamp, is in a predicatable location at skb_vnet_hdr.
> > >
> > > RFC: this implementation relies on the device writing to the buffer.
> > > That breaks DMA_TO_DEVICE semantics. For now, disable when DMA is on.
> > > The virtio changes should be a separate patch at the least.
> > >
> > > Tested: modified txtimestamp.c to with h/w timestamping:
> > >    -       sock_opt = SOF_TIMESTAMPING_SOFTWARE |
> > >    +       sock_opt = SOF_TIMESTAMPING_RAW_HARDWARE |
> > >    + do_test(family, SOF_TIMESTAMPING_TX_HARDWARE);
> > >
> > > Signed-off-by: Willem de Bruijn <willemb@google.com>
> > > ---
> > >   drivers/net/virtio_net.c        | 61 ++++++++++++++++++++++++++++-----
> > >   drivers/virtio/virtio_ring.c    |  3 +-
> > >   include/linux/virtio.h          |  1 +
> > >   include/uapi/linux/virtio_net.h |  1 +
> > >   4 files changed, 56 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index ac44c5efa0bc..fc8ecd3a333a 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -210,6 +210,12 @@ struct virtnet_info {
> > >     /* Device will pass rx timestamp. Requires has_rx_tstamp */
> > >     bool enable_rx_tstamp;
> > > +   /* Device can pass CLOCK_TAI transmit time to the driver */
> > > +   bool has_tx_tstamp;
> > > +
> > > +   /* Device will pass tx timestamp. Requires has_tx_tstamp */
> > > +   bool enable_tx_tstamp;
> > > +
> > >     /* Has control virtqueue */
> > >     bool has_cvq;
> > > @@ -1401,6 +1407,20 @@ static int virtnet_receive(struct receive_queue *rq, int budget,
> > >     return stats.packets;
> > >   }
> > > +static void virtnet_record_tx_tstamp(const struct send_queue *sq,
> > > +                                struct sk_buff *skb)
> > > +{
> > > +   const struct virtio_net_hdr_hash_ts *h = skb_vnet_hdr_ht(skb);
> > > +   const struct virtnet_info *vi = sq->vq->vdev->priv;
> > > +   struct skb_shared_hwtstamps ts;
> > > +
> > > +   if (h->hdr.flags & VIRTIO_NET_HDR_F_TSTAMP &&
> > > +       vi->enable_tx_tstamp) {
> > > +           ts.hwtstamp = ns_to_ktime(le64_to_cpu(h->tstamp));
> > > +           skb_tstamp_tx(skb, &ts);
> >
> >
> > This probably won't work since the buffer is read-only from the device. (See
> > virtqueue_add_outbuf()).
> >
> > Another issue that I vaguely remember that the virtio spec forbids out
> > buffer after in buffer.
>
> Both Driver Requirements: Message Framing and Driver Requirements: Scatter-Gather Support
> have this statement:
>
>         The driver MUST place any device-writable descriptor elements after any device-readable descriptor ele-
>         ments.
>
>
> similarly
>
> Device Requirements: The Virtqueue Descriptor Table
>         A device MUST NOT write to a device-readable buffer, and a device SHOULD NOT read a device-writable
>         buffer.

Thanks. That's clear. So the clean solution would be to add a
device-writable descriptor after the existing device-readable ones.

And the device must be aware that this is to return the tstamp only.
In the example implementation of vhost, it has to exclude this last
descriptor from the msg->msg_iter iovec array with packet data
initialized at get_tx_bufs/init_iov_iter.

  reply	other threads:[~2021-02-10  2:40 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08 18:55 [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp, tx-tstamp and tx-time Willem de Bruijn
2021-02-08 18:55 ` [PATCH RFC v2 1/4] virtio-net: support transmit hash report Willem de Bruijn
2021-02-08 18:55 ` [PATCH RFC v2 2/4] virtio-net: support receive timestamp Willem de Bruijn
2021-02-09  4:13   ` Jason Wang
2021-02-09 13:53     ` Willem de Bruijn
2021-02-10  4:10       ` Jason Wang
2021-02-08 18:55 ` [PATCH RFC v2 3/4] virtio-net: support transmit timestamp Willem de Bruijn
2021-02-09  5:45   ` Jason Wang
2021-02-09 16:38     ` Michael S. Tsirkin
2021-02-10  2:36       ` Willem de Bruijn [this message]
2021-02-10  4:15         ` Jason Wang
2021-02-10 14:40           ` Willem de Bruijn
2021-02-10  4:12       ` Jason Wang
2021-02-09  9:42   ` Michael S. Tsirkin
2021-02-09 14:45     ` Willem de Bruijn
2021-02-08 18:55 ` [PATCH RFC v2 4/4] virtio-net: support future packet transmit time Willem de Bruijn
2021-05-13 22:49 ` [PATCH RFC v2 0/4] virtio-net: add tx-hash, rx-tstamp, tx-tstamp and tx-time Willem de Bruijn
2021-05-14  7:12   ` Jason Wang
2021-05-14 12:46     ` Willem de Bruijn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAF=yD-Lw7LKypTLEfQmcqR9SwcL6f9wH=_yjQdyGak4ORegRug@mail.gmail.com' \
    --to=willemdebruijn.kernel@gmail.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willemb@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).