From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> To: Jason Wang <jasowang@redhat.com> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>, "Michael S. Tsirkin" <mst@redhat.com>, virtualization@lists.linux-foundation.org, Network Development <netdev@vger.kernel.org> Subject: Re: [PATCH rfc 2/3] virtio-net: support receive timestamp Date: Tue, 29 Dec 2020 09:20:14 -0500 [thread overview] Message-ID: <CA+FuTScycxSHqxvZZRjK9+tpXVV2iTv8vqeFc5U_m2CGDR3jog@mail.gmail.com> (raw) In-Reply-To: <1881606476.40780520.1609233449300.JavaMail.zimbra@redhat.com> On Tue, Dec 29, 2020 at 4:23 AM Jason Wang <jasowang@redhat.com> wrote: > > > > ----- Original Message ----- > > On Mon, Dec 28, 2020 at 7:55 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Mon, Dec 28, 2020 at 02:30:31PM -0500, Willem de Bruijn wrote: > > > > On Mon, Dec 28, 2020 at 12:29 PM Michael S. Tsirkin <mst@redhat.com> > > > > wrote: > > > > > > > > > > On Mon, Dec 28, 2020 at 11:22:32AM -0500, Willem de Bruijn wrote: > > > > > > From: Willem de Bruijn <willemb@google.com> > > > > > > > > > > > > Add optional PTP hardware timestamp offload for virtio-net. > > > > > > > > > > > > Accurate RTT measurement requires timestamps close to the wire. > > > > > > Introduce virtio feature VIRTIO_NET_F_RX_TSTAMP. If negotiated, the > > > > > > virtio-net header is expanded with room for a timestamp. A host may > > > > > > pass receive timestamps for all or some packets. A timestamp is valid > > > > > > if non-zero. > > > > > > > > > > > > The timestamp straddles (virtual) hardware domains. Like PTP, use > > > > > > international atomic time (CLOCK_TAI) as global clock base. It is > > > > > > guest responsibility to sync with host, e.g., through kvm-clock. > > > > > > > > > > > > Signed-off-by: Willem de Bruijn <willemb@google.com> > > > > > > diff --git a/include/uapi/linux/virtio_net.h > > > > > > b/include/uapi/linux/virtio_net.h > > > > > > index f6881b5b77ee..0ffe2eeebd4a 100644 > > > > > > --- a/include/uapi/linux/virtio_net.h > > > > > > +++ b/include/uapi/linux/virtio_net.h > > > > > > @@ -57,6 +57,7 @@ > > > > > > * Steering */ > > > > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > > > > > > > > > > > > +#define VIRTIO_NET_F_RX_TSTAMP 55 /* Host sends TAI > > > > > > receive time */ > > > > > > #define VIRTIO_NET_F_TX_HASH 56 /* Guest sends hash report */ > > > > > > #define VIRTIO_NET_F_HASH_REPORT 57 /* Supports hash report */ > > > > > > #define VIRTIO_NET_F_RSS 60 /* Supports RSS RX steering */ > > > > > > @@ -182,6 +183,17 @@ struct virtio_net_hdr_v1_hash { > > > > > > }; > > > > > > }; > > > > > > > > > > > > +struct virtio_net_hdr_v12 { > > > > > > + struct virtio_net_hdr_v1 hdr; > > > > > > + struct { > > > > > > + __le32 value; > > > > > > + __le16 report; > > > > > > + __le16 flow_state; > > > > > > + } hash; > > > > > > + __virtio32 reserved; > > > > > > + __virtio64 tstamp; > > > > > > +}; > > > > > > + > > > > > > #ifndef VIRTIO_NET_NO_LEGACY > > > > > > /* This header comes first in the scatter-gather list. > > > > > > * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it > > > > > > must > > > > > > > > > > > > > > > So it looks like VIRTIO_NET_F_RX_TSTAMP should depend on both > > > > > VIRTIO_NET_F_RX_TSTAMP and VIRTIO_NET_F_HASH_REPORT then? > > > > > > > > Do you mean VIRTIO_NET_F_TX_TSTAMP depends on VIRTIO_NET_F_RX_TSTAMP? > > > > > > > > I think if either is enabled we need to enable the extended layout. > > > > Regardless of whether TX_HASH or HASH_REPORT are enabled. If they are > > > > not, then those fields are ignored. > > > > > > I mean do we waste the 8 bytes for hash if TSTAMP is set but HASH is not? > > > If TSTAMP depends on HASH then point is moot. > > > > True, but the two features really are independent. > > > > I did consider using configurable metadata layout depending on > > features negotiated. If there are tons of optional extensions, that > > makes sense. But it is more complex and parsing error prone. With a > > handful of options each of a few bytes, that did not seem worth the > > cost to me at this point. > > Consider NFV workloads(64B) packet. Most fields of current vnet header > is even a burdern. Such workloads will not negotiate these features, I imagine. I think this could only become an issue if a small packet workload would want to negotiate one optional feature, without the others. Even then, the actual cost of a few untouched bytes is negligible, as long as the headers don't span cache-lines. I expect it to be cheaper than having to parse a dynamic layout. > It might be the time to introduce configurable or > self-descriptive vnet header. I did briefly toy with a type-val encoding. Not type-val-len, as all options have fixed length (so far), so length can be left implicit. But as each feature is negotiated before hand, the type can be left implicit too. Leaving just the data elements tightly packed. As long as order is defined. > > And importantly, such a mode can always be added later as a separate > > VIRTIO_NET_F_PACKED_HEADER option. > > What will do feature provide? The tightly packed data elements. Strip out the elements for non negotiated features. So if either tstamp option is negotiated, but hash is not, exclude the 64b of hash fields. Note that I'm not actually arguing for this (at this point).
WARNING: multiple messages have this Message-ID (diff)
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com> To: Jason Wang <jasowang@redhat.com> Cc: Network Development <netdev@vger.kernel.org>, Willem de Bruijn <willemdebruijn.kernel@gmail.com>, virtualization@lists.linux-foundation.org, "Michael S. Tsirkin" <mst@redhat.com> Subject: Re: [PATCH rfc 2/3] virtio-net: support receive timestamp Date: Tue, 29 Dec 2020 09:20:14 -0500 [thread overview] Message-ID: <CA+FuTScycxSHqxvZZRjK9+tpXVV2iTv8vqeFc5U_m2CGDR3jog@mail.gmail.com> (raw) In-Reply-To: <1881606476.40780520.1609233449300.JavaMail.zimbra@redhat.com> On Tue, Dec 29, 2020 at 4:23 AM Jason Wang <jasowang@redhat.com> wrote: > > > > ----- Original Message ----- > > On Mon, Dec 28, 2020 at 7:55 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Mon, Dec 28, 2020 at 02:30:31PM -0500, Willem de Bruijn wrote: > > > > On Mon, Dec 28, 2020 at 12:29 PM Michael S. Tsirkin <mst@redhat.com> > > > > wrote: > > > > > > > > > > On Mon, Dec 28, 2020 at 11:22:32AM -0500, Willem de Bruijn wrote: > > > > > > From: Willem de Bruijn <willemb@google.com> > > > > > > > > > > > > Add optional PTP hardware timestamp offload for virtio-net. > > > > > > > > > > > > Accurate RTT measurement requires timestamps close to the wire. > > > > > > Introduce virtio feature VIRTIO_NET_F_RX_TSTAMP. If negotiated, the > > > > > > virtio-net header is expanded with room for a timestamp. A host may > > > > > > pass receive timestamps for all or some packets. A timestamp is valid > > > > > > if non-zero. > > > > > > > > > > > > The timestamp straddles (virtual) hardware domains. Like PTP, use > > > > > > international atomic time (CLOCK_TAI) as global clock base. It is > > > > > > guest responsibility to sync with host, e.g., through kvm-clock. > > > > > > > > > > > > Signed-off-by: Willem de Bruijn <willemb@google.com> > > > > > > diff --git a/include/uapi/linux/virtio_net.h > > > > > > b/include/uapi/linux/virtio_net.h > > > > > > index f6881b5b77ee..0ffe2eeebd4a 100644 > > > > > > --- a/include/uapi/linux/virtio_net.h > > > > > > +++ b/include/uapi/linux/virtio_net.h > > > > > > @@ -57,6 +57,7 @@ > > > > > > * Steering */ > > > > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */ > > > > > > > > > > > > +#define VIRTIO_NET_F_RX_TSTAMP 55 /* Host sends TAI > > > > > > receive time */ > > > > > > #define VIRTIO_NET_F_TX_HASH 56 /* Guest sends hash report */ > > > > > > #define VIRTIO_NET_F_HASH_REPORT 57 /* Supports hash report */ > > > > > > #define VIRTIO_NET_F_RSS 60 /* Supports RSS RX steering */ > > > > > > @@ -182,6 +183,17 @@ struct virtio_net_hdr_v1_hash { > > > > > > }; > > > > > > }; > > > > > > > > > > > > +struct virtio_net_hdr_v12 { > > > > > > + struct virtio_net_hdr_v1 hdr; > > > > > > + struct { > > > > > > + __le32 value; > > > > > > + __le16 report; > > > > > > + __le16 flow_state; > > > > > > + } hash; > > > > > > + __virtio32 reserved; > > > > > > + __virtio64 tstamp; > > > > > > +}; > > > > > > + > > > > > > #ifndef VIRTIO_NET_NO_LEGACY > > > > > > /* This header comes first in the scatter-gather list. > > > > > > * For legacy virtio, if VIRTIO_F_ANY_LAYOUT is not negotiated, it > > > > > > must > > > > > > > > > > > > > > > So it looks like VIRTIO_NET_F_RX_TSTAMP should depend on both > > > > > VIRTIO_NET_F_RX_TSTAMP and VIRTIO_NET_F_HASH_REPORT then? > > > > > > > > Do you mean VIRTIO_NET_F_TX_TSTAMP depends on VIRTIO_NET_F_RX_TSTAMP? > > > > > > > > I think if either is enabled we need to enable the extended layout. > > > > Regardless of whether TX_HASH or HASH_REPORT are enabled. If they are > > > > not, then those fields are ignored. > > > > > > I mean do we waste the 8 bytes for hash if TSTAMP is set but HASH is not? > > > If TSTAMP depends on HASH then point is moot. > > > > True, but the two features really are independent. > > > > I did consider using configurable metadata layout depending on > > features negotiated. If there are tons of optional extensions, that > > makes sense. But it is more complex and parsing error prone. With a > > handful of options each of a few bytes, that did not seem worth the > > cost to me at this point. > > Consider NFV workloads(64B) packet. Most fields of current vnet header > is even a burdern. Such workloads will not negotiate these features, I imagine. I think this could only become an issue if a small packet workload would want to negotiate one optional feature, without the others. Even then, the actual cost of a few untouched bytes is negligible, as long as the headers don't span cache-lines. I expect it to be cheaper than having to parse a dynamic layout. > It might be the time to introduce configurable or > self-descriptive vnet header. I did briefly toy with a type-val encoding. Not type-val-len, as all options have fixed length (so far), so length can be left implicit. But as each feature is negotiated before hand, the type can be left implicit too. Leaving just the data elements tightly packed. As long as order is defined. > > And importantly, such a mode can always be added later as a separate > > VIRTIO_NET_F_PACKED_HEADER option. > > What will do feature provide? The tightly packed data elements. Strip out the elements for non negotiated features. So if either tstamp option is negotiated, but hash is not, exclude the 64b of hash fields. Note that I'm not actually arguing for this (at this point). _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-12-29 14:22 UTC|newest] Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-28 16:22 [PATCH rfc 0/3] virtio-net: add tx-hash, rx-tstamp and tx-tstamp Willem de Bruijn 2020-12-28 16:22 ` Willem de Bruijn 2020-12-28 16:22 ` [PATCH rfc 1/3] virtio-net: support transmit hash report Willem de Bruijn 2020-12-28 16:22 ` Willem de Bruijn 2020-12-28 16:28 ` Michael S. Tsirkin 2020-12-28 16:28 ` Michael S. Tsirkin 2020-12-28 16:47 ` Willem de Bruijn 2020-12-28 16:47 ` Willem de Bruijn 2020-12-28 17:22 ` Michael S. Tsirkin 2020-12-28 17:22 ` Michael S. Tsirkin 2020-12-29 1:19 ` Willem de Bruijn 2020-12-29 1:19 ` Willem de Bruijn 2020-12-28 21:36 ` Michael S. Tsirkin 2020-12-28 21:36 ` Michael S. Tsirkin 2020-12-29 1:23 ` Willem de Bruijn 2020-12-29 1:23 ` Willem de Bruijn 2020-12-28 16:22 ` [PATCH rfc 2/3] virtio-net: support receive timestamp Willem de Bruijn 2020-12-28 16:22 ` Willem de Bruijn 2020-12-28 17:28 ` Michael S. Tsirkin 2020-12-28 17:28 ` Michael S. Tsirkin 2020-12-28 19:30 ` Willem de Bruijn 2020-12-28 19:30 ` Willem de Bruijn 2020-12-28 21:32 ` Michael S. Tsirkin 2020-12-28 21:32 ` Michael S. Tsirkin 2020-12-29 1:05 ` Willem de Bruijn 2020-12-29 1:05 ` Willem de Bruijn 2020-12-29 9:17 ` Jason Wang 2020-12-29 9:17 ` Jason Wang 2020-12-29 14:20 ` Willem de Bruijn [this message] 2020-12-29 14:20 ` Willem de Bruijn 2020-12-30 8:38 ` Jason Wang 2020-12-30 8:38 ` Jason Wang 2020-12-28 22:59 ` Jakub Kicinski 2020-12-29 0:57 ` Willem de Bruijn 2020-12-29 0:57 ` Willem de Bruijn 2020-12-30 8:44 ` Jason Wang 2020-12-30 8:44 ` Jason Wang 2020-12-30 12:30 ` Richard Cochran 2021-02-02 13:05 ` kernel test robot 2021-02-02 13:05 ` kernel test robot 2021-02-02 13:05 ` kernel test robot 2021-02-02 14:08 ` Michael S. Tsirkin 2021-02-02 14:08 ` Michael S. Tsirkin 2021-02-02 22:17 ` Willem de Bruijn 2021-02-02 22:17 ` Willem de Bruijn 2021-02-02 23:02 ` Michael S. Tsirkin 2021-02-02 23:02 ` Michael S. Tsirkin 2021-02-02 23:43 ` Willem de Bruijn 2021-02-02 23:43 ` Willem de Bruijn 2020-12-28 16:22 ` [PATCH rfc 3/3] virtio-net: support transmit timestamp Willem de Bruijn 2020-12-28 16:22 ` Willem de Bruijn 2020-12-30 12:38 ` Richard Cochran 2020-12-30 15:25 ` Willem de Bruijn 2020-12-30 15:25 ` Willem de Bruijn 2021-02-02 13:47 ` kernel test robot 2021-02-02 13:47 ` kernel test robot 2021-02-02 13:47 ` kernel test robot 2020-12-28 17:29 ` [PATCH rfc 0/3] virtio-net: add tx-hash, rx-tstamp and tx-tstamp Michael S. Tsirkin 2020-12-28 17:29 ` Michael S. Tsirkin 2020-12-28 19:51 ` Willem de Bruijn 2020-12-28 19:51 ` Willem de Bruijn 2020-12-28 21:38 ` Michael S. Tsirkin 2020-12-28 21:38 ` Michael S. Tsirkin 2020-12-29 1:14 ` Willem de Bruijn 2020-12-29 1:14 ` Willem de Bruijn 2021-01-06 20:32 ` Willem de Bruijn 2021-01-06 20:32 ` 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=CA+FuTScycxSHqxvZZRjK9+tpXVV2iTv8vqeFc5U_m2CGDR3jog@mail.gmail.com \ --to=willemdebruijn.kernel@gmail.com \ --cc=jasowang@redhat.com \ --cc=mst@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=virtualization@lists.linux-foundation.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.