From: Jason Wang <jasowang@redhat.com> To: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: virtualization@lists.linux-foundation.org, Network Development <netdev@vger.kernel.org>, "Michael S. Tsirkin" <mst@redhat.com>, Richard Cochran <richardcochran@gmail.com>, Willem de Bruijn <willemb@google.com> Subject: Re: [PATCH RFC v2 2/4] virtio-net: support receive timestamp Date: Wed, 10 Feb 2021 12:10:47 +0800 [thread overview] Message-ID: <7ed23e65-b6b9-c699-b9aa-69aaf07034d0@redhat.com> (raw) In-Reply-To: <CAF=yD-Jkm-Cfs2tHKhC17KfPp+=18y=9_XSuY-LNgkC-2_NfLA@mail.gmail.com> On 2021/2/9 下午9:53, Willem de Bruijn wrote: > On Mon, Feb 8, 2021 at 11:13 PM Jason Wang <jasowang@redhat.com> wrote: >> >> On 2021/2/9 上午2:55, Willem de Bruijn wrote: >>> From: Willem de Bruijn <willemb@google.com> >>> >>> Add optional PTP hardware rx 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 device may pass receive timestamps for all or some packets. Flag >>> VIRTIO_NET_HDR_F_TSTAMP signals whether a timestamp is recorded. >>> >>> A driver that supports hardware timestamping must also support >>> ioctl SIOCSHWTSTAMP. Implement that, as well as information getters >>> ioctl SIOCGHWTSTAMP and ethtool get_ts_info (`ethtool -T $DEV`). >>> >>> 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. >>> >>> Tested: >>> guest: ./timestamping eth0 \ >>> SOF_TIMESTAMPING_RAW_HARDWARE \ >>> SOF_TIMESTAMPING_RX_HARDWARE >>> host: nc -4 -u 192.168.1.1 319 >>> >>> Changes RFC -> RFCv2 >>> - rename virtio_net_hdr_v12 to virtio_net_hdr_hash_ts >>> - add ethtool .get_ts_info to query capabilities >>> - add ioctl SIOC[GS]HWTSTAMP to configure feature >>> - add vi->enable_rx_tstamp to store configuration >>> - convert virtioXX_to_cpu to leXX_to_cpu >>> - convert reserved to __u32 >>> >>> Signed-off-by: Willem de Bruijn <willemb@google.com> >>> static const struct net_device_ops virtnet_netdev = { >>> .ndo_open = virtnet_open, >>> .ndo_stop = virtnet_close, >>> @@ -2573,6 +2676,7 @@ static const struct net_device_ops virtnet_netdev = { >>> .ndo_features_check = passthru_features_check, >>> .ndo_get_phys_port_name = virtnet_get_phys_port_name, >>> .ndo_set_features = virtnet_set_features, >>> + .ndo_do_ioctl = virtnet_ioctl, >>> }; >>> >>> static void virtnet_config_changed_work(struct work_struct *work) >>> @@ -3069,6 +3173,11 @@ static int virtnet_probe(struct virtio_device *vdev) >>> vi->hdr_len = sizeof(struct virtio_net_hdr_v1_hash); >>> } >>> >>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_RX_TSTAMP)) { >>> + vi->has_rx_tstamp = true; >>> + vi->hdr_len = sizeof(struct virtio_net_hdr_hash_ts); >> >> Does this mean even if the device doesn't pass timestamp, the header >> still contains the timestamp fields. > Yes. As implemented, the size of the header is constant across > packets. If both sides negotiate the feature, then all headers reserve > space, whether or not the specific packet has a timestamp. > > So far headers are fixed size. I suppose we could investigate variable > size headers. This goes back to our discussion in the previous > patchset, that we can always add a packed-header feature later, if the > number of optional features reaches a size that makes the complexity > worthwhile. Right, so for timstamp it's probably OK but we probably need to do as you said here if we want to add more in the header. Let's see how Michael think about this. > >>> + } >>> + >>> if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT) || >>> virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) >>> vi->any_header_sg = true; >>> @@ -3260,7 +3369,7 @@ static struct virtio_device_id id_table[] = { >>> VIRTIO_NET_F_CTRL_MAC_ADDR, \ >>> VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \ >>> VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY, \ >>> - VIRTIO_NET_F_TX_HASH >>> + VIRTIO_NET_F_TX_HASH, VIRTIO_NET_F_RX_TSTAMP >>> >>> static unsigned int features[] = { >>> VIRTNET_FEATURES, >>> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h >>> index 273d43c35f59..a5c84410cf92 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 /* Device sends TAI receive time */ >>> #define VIRTIO_NET_F_TX_HASH 56 /* Driver sends hash report */ >>> #define VIRTIO_NET_F_HASH_REPORT 57 /* Supports hash report */ >>> #define VIRTIO_NET_F_RSS 60 /* Supports RSS RX steering */ >>> @@ -126,6 +127,7 @@ struct virtio_net_hdr_v1 { >>> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */ >>> #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */ >>> #define VIRTIO_NET_HDR_F_RSC_INFO 4 /* rsc info in csum_ fields */ >>> +#define VIRTIO_NET_HDR_F_TSTAMP 8 /* timestamp is recorded */ >>> __u8 flags; >>> #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */ >>> #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */ >>> @@ -181,6 +183,17 @@ struct virtio_net_hdr_v1_hash { >>> }; >>> }; >>> >>> +struct virtio_net_hdr_hash_ts { >>> + struct virtio_net_hdr_v1 hdr; >>> + struct { >>> + __le32 value; >>> + __le16 report; >>> + __le16 flow_state; >>> + } hash; >> >> Any reason for not embedding structure virtio_net_hdr_v1_hash? > Just that it becomes an onion of struct inside structs. I can change > if you prefer. Yes please (unless Michael has other opinion). > >> Thanks > As always, thanks for reviewing, Jason. > You're welcome :) Thanks
WARNING: multiple messages have this Message-ID (diff)
From: Jason Wang <jasowang@redhat.com> To: Willem de Bruijn <willemdebruijn.kernel@gmail.com> Cc: Network Development <netdev@vger.kernel.org>, Richard Cochran <richardcochran@gmail.com>, "Michael S. Tsirkin" <mst@redhat.com>, Willem de Bruijn <willemb@google.com>, virtualization@lists.linux-foundation.org Subject: Re: [PATCH RFC v2 2/4] virtio-net: support receive timestamp Date: Wed, 10 Feb 2021 12:10:47 +0800 [thread overview] Message-ID: <7ed23e65-b6b9-c699-b9aa-69aaf07034d0@redhat.com> (raw) In-Reply-To: <CAF=yD-Jkm-Cfs2tHKhC17KfPp+=18y=9_XSuY-LNgkC-2_NfLA@mail.gmail.com> On 2021/2/9 下午9:53, Willem de Bruijn wrote: > On Mon, Feb 8, 2021 at 11:13 PM Jason Wang <jasowang@redhat.com> wrote: >> >> On 2021/2/9 上午2:55, Willem de Bruijn wrote: >>> From: Willem de Bruijn <willemb@google.com> >>> >>> Add optional PTP hardware rx 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 device may pass receive timestamps for all or some packets. Flag >>> VIRTIO_NET_HDR_F_TSTAMP signals whether a timestamp is recorded. >>> >>> A driver that supports hardware timestamping must also support >>> ioctl SIOCSHWTSTAMP. Implement that, as well as information getters >>> ioctl SIOCGHWTSTAMP and ethtool get_ts_info (`ethtool -T $DEV`). >>> >>> 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. >>> >>> Tested: >>> guest: ./timestamping eth0 \ >>> SOF_TIMESTAMPING_RAW_HARDWARE \ >>> SOF_TIMESTAMPING_RX_HARDWARE >>> host: nc -4 -u 192.168.1.1 319 >>> >>> Changes RFC -> RFCv2 >>> - rename virtio_net_hdr_v12 to virtio_net_hdr_hash_ts >>> - add ethtool .get_ts_info to query capabilities >>> - add ioctl SIOC[GS]HWTSTAMP to configure feature >>> - add vi->enable_rx_tstamp to store configuration >>> - convert virtioXX_to_cpu to leXX_to_cpu >>> - convert reserved to __u32 >>> >>> Signed-off-by: Willem de Bruijn <willemb@google.com> >>> static const struct net_device_ops virtnet_netdev = { >>> .ndo_open = virtnet_open, >>> .ndo_stop = virtnet_close, >>> @@ -2573,6 +2676,7 @@ static const struct net_device_ops virtnet_netdev = { >>> .ndo_features_check = passthru_features_check, >>> .ndo_get_phys_port_name = virtnet_get_phys_port_name, >>> .ndo_set_features = virtnet_set_features, >>> + .ndo_do_ioctl = virtnet_ioctl, >>> }; >>> >>> static void virtnet_config_changed_work(struct work_struct *work) >>> @@ -3069,6 +3173,11 @@ static int virtnet_probe(struct virtio_device *vdev) >>> vi->hdr_len = sizeof(struct virtio_net_hdr_v1_hash); >>> } >>> >>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_RX_TSTAMP)) { >>> + vi->has_rx_tstamp = true; >>> + vi->hdr_len = sizeof(struct virtio_net_hdr_hash_ts); >> >> Does this mean even if the device doesn't pass timestamp, the header >> still contains the timestamp fields. > Yes. As implemented, the size of the header is constant across > packets. If both sides negotiate the feature, then all headers reserve > space, whether or not the specific packet has a timestamp. > > So far headers are fixed size. I suppose we could investigate variable > size headers. This goes back to our discussion in the previous > patchset, that we can always add a packed-header feature later, if the > number of optional features reaches a size that makes the complexity > worthwhile. Right, so for timstamp it's probably OK but we probably need to do as you said here if we want to add more in the header. Let's see how Michael think about this. > >>> + } >>> + >>> if (virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT) || >>> virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) >>> vi->any_header_sg = true; >>> @@ -3260,7 +3369,7 @@ static struct virtio_device_id id_table[] = { >>> VIRTIO_NET_F_CTRL_MAC_ADDR, \ >>> VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \ >>> VIRTIO_NET_F_SPEED_DUPLEX, VIRTIO_NET_F_STANDBY, \ >>> - VIRTIO_NET_F_TX_HASH >>> + VIRTIO_NET_F_TX_HASH, VIRTIO_NET_F_RX_TSTAMP >>> >>> static unsigned int features[] = { >>> VIRTNET_FEATURES, >>> diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h >>> index 273d43c35f59..a5c84410cf92 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 /* Device sends TAI receive time */ >>> #define VIRTIO_NET_F_TX_HASH 56 /* Driver sends hash report */ >>> #define VIRTIO_NET_F_HASH_REPORT 57 /* Supports hash report */ >>> #define VIRTIO_NET_F_RSS 60 /* Supports RSS RX steering */ >>> @@ -126,6 +127,7 @@ struct virtio_net_hdr_v1 { >>> #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */ >>> #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */ >>> #define VIRTIO_NET_HDR_F_RSC_INFO 4 /* rsc info in csum_ fields */ >>> +#define VIRTIO_NET_HDR_F_TSTAMP 8 /* timestamp is recorded */ >>> __u8 flags; >>> #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */ >>> #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */ >>> @@ -181,6 +183,17 @@ struct virtio_net_hdr_v1_hash { >>> }; >>> }; >>> >>> +struct virtio_net_hdr_hash_ts { >>> + struct virtio_net_hdr_v1 hdr; >>> + struct { >>> + __le32 value; >>> + __le16 report; >>> + __le16 flow_state; >>> + } hash; >> >> Any reason for not embedding structure virtio_net_hdr_v1_hash? > Just that it becomes an onion of struct inside structs. I can change > if you prefer. Yes please (unless Michael has other opinion). > >> Thanks > As always, thanks for reviewing, Jason. > You're welcome :) Thanks _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-02-10 4:12 UTC|newest] Thread overview: 35+ 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 ` 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 ` Willem de Bruijn 2021-02-08 18:55 ` [PATCH RFC v2 2/4] virtio-net: support receive timestamp Willem de Bruijn 2021-02-08 18:55 ` Willem de Bruijn 2021-02-09 4:13 ` Jason Wang 2021-02-09 13:53 ` Willem de Bruijn 2021-02-09 13:53 ` Willem de Bruijn 2021-02-10 4:10 ` Jason Wang [this message] 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-08 18:55 ` Willem de Bruijn 2021-02-09 5:45 ` Jason Wang 2021-02-09 5:45 ` Jason Wang 2021-02-09 16:38 ` Michael S. Tsirkin 2021-02-09 16:38 ` Michael S. Tsirkin 2021-02-10 2:36 ` Willem de Bruijn 2021-02-10 2:36 ` Willem de Bruijn 2021-02-10 4:15 ` Jason Wang 2021-02-10 4:15 ` Jason Wang 2021-02-10 14:40 ` Willem de Bruijn 2021-02-10 14:40 ` Willem de Bruijn 2021-02-10 4:12 ` Jason Wang 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-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-02-08 18:55 ` 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 7:12 ` Jason Wang 2021-05-14 12:46 ` Willem de Bruijn 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=7ed23e65-b6b9-c699-b9aa-69aaf07034d0@redhat.com \ --to=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 \ --cc=willemdebruijn.kernel@gmail.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: 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.