OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-comment] Re: [virtio] [PATCH requirements 6/7] net-features: Add packet timestamp requirements


On Wed, Aug 9, 2023 at 4:47âPM Xuan Zhuo <xuanzhuo@linux.alibaba.com> wrote:
>
> On Mon, 24 Jul 2023 06:34:20 +0300, Parav Pandit <parav@nvidia.com> wrote:
> > Add tx and rx packet timestamp requirements.
> >
> > Signed-off-by: Parav Pandit <parav@nvidia.com>
> > ---
> >  net-workstream/features-1.4.md | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> >
> > diff --git a/net-workstream/features-1.4.md b/net-workstream/features-1.4.md
> > index d228462..37820b6 100644
> > --- a/net-workstream/features-1.4.md
> > +++ b/net-workstream/features-1.4.md
> > @@ -10,6 +10,7 @@ together is desired while updating the virtio net interface.
> >  2. Low latency tx and rx virtqueues for PCI transport
> >  3. Virtqueue notification coalescing re-arming support
> >  4  Virtqueue receive flow filters (RFF)
> > +5. Device timestamp for tx and rx packets
> >
> >  # 3. Requirements
> >  ## 3.1 Device counters
> > @@ -280,3 +281,28 @@ struct virtio_net_rff_delete {
> >       u8 padding[2];
> >       le32 flow_id;
> >  };
> > +
> > +## 3.5 Packet timestamp
> > +1. Device should provide transmit timestamp and receive timestamp of the packets
> > +   at per packet level when the device is enabled.
> > +2. Device should provide the current free running clock in the least latency
> > +   possible using an MMIO register read of 64-bit to have the least jitter.
> > +3. Device should provide the current frequency and the frequency unit for the
> > +   software to synchronize the reference point of software and the device using
> > +   a control vq command.
> > +
> > +### 3.5.1 Transmit timestamp
> > +1. Transmit completion must contain a packet transmission timestamp when the
> > +   device is enabled for it.
> > +2. The device should record the packet transmit timestamp in the completion at
> > +   the farthest egress point towards the network.
> > +3. The device must provide a transmit packet timestamp in a single DMA
> > +   transaction along with the rest of the transmit completion fields.
> > +
> > +### 3.5.2 Receive timestamp
> > +1. Receive completion must contain a packet reception timestamp when the device
> > +   is enabled for it.
> > +2. The device should record the received packet timestamp at the closet ingress
> > +   point of reception from the network.
> > +3. The device should provide a receive packet timestamp in a single DMA
> > +   transaction along with the rest of the receive completion fields.
>
>
> According to the last discuss, the feature will depend on the new desc
> structure.
>
> I would to know, can we introduce this to the current spec with a simple change?
>
>  struct vring_used_elem {
>         /* Index of start of used descriptor chain. */
>         __virtio32 id;
>         /* Total length of the descriptor chain which was used (written to) */
>         __virtio32 len;
>
> +       __virtio64 timestamp;
>  };

I think this could be one way and another proposal from Willem is:

https://lists.linuxfoundation.org/pipermail/virtualization/2021-February/052422.html

which might be tricky for TX but it's more flexible since it allows
timestamps to be done per buffer.

>
>
> Then, the existing devices can support this easily. If we introduce this by the
> new desc structure, we can foresee that this function will not be implemented by
> many existing machines. But this function is useful. So we want support this by
> a simple way.

Make sense.

Thanks

>
>
> Thanks.
>
> > --
> > 2.26.2
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
> This publicly archived list offers a means to provide input to the
> OASIS Virtual I/O Device (VIRTIO) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> List help: virtio-comment-help@lists.oasis-open.org
> List archive: https://lists.oasis-open.org/archives/virtio-comment/
> Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
> Committee: https://www.oasis-open.org/committees/virtio/
> Join OASIS: https://www.oasis-open.org/join/
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]