From: Parav Pandit <parav@nvidia.com>
To: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Jason Wang <jasowang@redhat.com>,
Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
Shahaf Shuler <shahafs@nvidia.com>,
"hengqi@linux.alibaba.com" <hengqi@linux.alibaba.com>,
"virtio@lists.oasis-open.org" <virtio@lists.oasis-open.org>,
"virtio-comment@lists.oasis-open.org"
<virtio-comment@lists.oasis-open.org>,
Willem de Bruijn <willemb@google.com>,
Stanislav Fomichev <sdf@google.com>
Subject: RE: [virtio-comment] Re: [virtio] [PATCH requirements 6/7] net-features: Add packet timestamp requirements
Date: Wed, 16 Aug 2023 04:10:21 +0000 [thread overview]
Message-ID: <PH0PR12MB54810B9363ACD3E13FE328C5DC15A@PH0PR12MB5481.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAF=yD-LXtrQeW0GnTR0BeDuExN5aBLC4dGEfdWbjtxmhNY2G6g@mail.gmail.com>
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Sent: Tuesday, August 15, 2023 8:21 PM
> > Thanks for the above pointer and your inputs, we are considering many of
> them in 1.4 timeframe.
> > Many are post 1.4 so that one can implement also in practical time
> > frame :)
>
> Just be careful about precise use of terminology around this topic:
> uncertainty, precision and the like.
>
> For example, "a single MMIO read of a 64-bit register gives the lowest latency"
> perhaps can use some clarification.
>
Lower latency compared to accessing it via cvq interface.
> In clock synchronization, goal is not to minimize latency of the synchronization
> operation itself, but of the capture of the two timestamps.
>
Right.
> Which is why PCIe PTM and others use a sandwich of host_ts - device_ts
> - host_ts. The latency between these timestamps is what matters.
>
Will update to follow this as well. Was hoping to merge with the rtc work ongoing in the virtio to have as part of the net device.
> A single register read is certainly simplest. And it may be correct.
> But be careful if it is strictly worse than returning a pair of timestamps, like
> ptp_clock_info.getcrosststamp. The initial partial implementation should not
> become obsolete as we fill in the details later.
>
I guess it won't be because sandwich mode is still possible with/without mmio.
We can move to read via the queue itself.
> > > Virtio defines both a virtual interface and one that can be
> > > supported by hardware, so it's not a 1:1 match, but many subtle
> > > points probably apply to both.
> > >
> > Yes, it does and the proposal here in first phase is to support both so that
> precision may not be nsec level but at usec for semi virtual interfaces.
> > And progress towards supporting PTM after that.
> >
> > >
> > > For timestamping, the difficult part is the transmit completion
> > > stamp, asynchronous with data flow. If this is taken on the device
> > > before or at the time of queuing the completion to the host, then it
> > > can be stored in\ the completion descriptor.
> > At this point we are considering before the PHY and after the queuing as
> listed in this doc.
> > So that completion can hold this.
>
> Ack. Sounds good.
>
> This Tx timestamp is the one where you pointed out that my series was worse
> because "Mainly it incurs yet additional DMA for timestamp that must be
> avoided.", right?
>
Right.
> >
> > > But if taken at the PHY, say, it is not uncommon for this to happen
> > > after the completion is written. And instead a block of dedicated
> > > registers is used and the host must poll a register. There are
> > > examples of these in the Linux device driver directory. For virtio,
> > > it is probably sufficient to only support the first kind.
> > >
> > We do not have good abstraction of the PHY yet and it is bit hard to adopt to
> phy when its mix of virtual and physical.
> > So current plan is to place them in the completions for tx and rx.
>
> Same as above. Sounds entirely reasonable to me. Just wanted to point out this
> limitation / possible future extension.
True.
next prev parent reply other threads:[~2023-08-16 4:10 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 3:34 [virtio-comment] [PATCH requirements 0/7] virtio net new features requirements Parav Pandit
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 1/7] net-features: Add requirements document for release 1.4 Parav Pandit
2023-08-08 8:16 ` David Edmondson
2023-08-14 5:17 ` Parav Pandit
2023-08-14 11:53 ` David Edmondson
2023-08-14 11:56 ` David Edmondson
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 2/7] net-features: Add low latency transmit queue requirements Parav Pandit
2023-08-08 8:24 ` David Edmondson
2023-08-10 19:05 ` [virtio-comment] RE: [EXT] [virtio] " Satananda Burla
2023-08-15 5:51 ` Parav Pandit
2023-08-14 11:55 ` [virtio-comment] " David Edmondson
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 3/7] net-features: Add low latency receive " Parav Pandit
2023-08-08 8:32 ` David Edmondson
2023-08-14 11:54 ` David Edmondson
2023-08-15 4:45 ` Parav Pandit
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 4/7] net-features: Add notification coalescing requirements Parav Pandit
2023-08-14 11:57 ` David Edmondson
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 5/7] net-features: Add n-tuple receive flow filters requirements Parav Pandit
2023-08-01 8:33 ` [virtio-comment] " Parav Pandit
2023-08-02 6:44 ` Parav Pandit
2023-08-02 15:32 ` Heng Qi
2023-08-03 10:01 ` Parav Pandit
2023-08-03 13:11 ` [virtio-comment] Re: [virtio] " Heng Qi
2023-08-02 7:17 ` [virtio-comment] RE: [EXT] [virtio] " Satananda Burla
2023-08-02 8:14 ` Parav Pandit
2023-08-02 18:32 ` Satananda Burla
2023-08-04 7:32 ` Parav Pandit
2023-08-02 15:25 ` [virtio-comment] " Heng Qi
2023-08-03 9:59 ` [virtio-comment] " Parav Pandit
2023-08-03 13:07 ` [virtio-comment] " Heng Qi
2023-08-04 6:20 ` [virtio-comment] " Parav Pandit
2023-08-04 7:17 ` [virtio-comment] " Heng Qi
2023-08-04 7:30 ` [virtio-comment] " Parav Pandit
2023-08-04 7:51 ` [virtio-comment] Re: [virtio] " Heng Qi
2023-08-07 7:22 ` Heng Qi
2023-08-08 7:13 ` Parav Pandit
2023-08-08 8:18 ` [virtio-comment] Re: [virtio] " Heng Qi
2023-08-08 8:21 ` [virtio-comment] " Heng Qi
2023-08-14 5:15 ` [virtio-comment] " Parav Pandit
2023-08-14 6:18 ` [virtio-comment] " Heng Qi
2023-08-14 6:35 ` [virtio-comment] " Parav Pandit
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 6/7] net-features: Add packet timestamp requirements Parav Pandit
2023-08-09 8:35 ` [virtio-comment] Re: [virtio] " Xuan Zhuo
2023-08-10 6:56 ` Jason Wang
2023-08-15 6:13 ` Parav Pandit
[not found] ` <CAF=yD-+LMY3yE3qtd4vHc8CGOz6UAf4njM2QiZcajrQgL=KZRQ@mail.gmail.com>
2023-08-14 2:54 ` Jason Wang
2023-08-15 6:26 ` Parav Pandit
[not found] ` <CAF=yD-LXtrQeW0GnTR0BeDuExN5aBLC4dGEfdWbjtxmhNY2G6g@mail.gmail.com>
2023-08-16 4:10 ` Parav Pandit [this message]
2023-08-14 13:06 ` [virtio-comment] " Parav Pandit
2023-08-15 2:47 ` [virtio-comment] " Xuan Zhuo
2023-08-15 4:01 ` [virtio-comment] " Parav Pandit
2023-08-15 6:01 ` [virtio-comment] " Xuan Zhuo
2023-08-15 6:09 ` [virtio-comment] " Parav Pandit
2023-08-15 9:44 ` [virtio-comment] " Xuan Zhuo
2023-08-14 11:59 ` [virtio-comment] " David Edmondson
2023-07-24 3:34 ` [virtio-comment] [PATCH requirements 7/7] net-features: Add header data split requirements Parav Pandit
2023-08-10 19:19 ` [virtio-comment] RE: [EXT] [virtio] " Satananda Burla
2023-08-14 12:00 ` [virtio-comment] " David Edmondson
[not found] ` <CA+FuTSeguCKk4zxZ0=Ebr1phZhF9kssHeGPn2eZj6SRNv2ewsA@mail.gmail.com>
2023-08-14 13:09 ` [virtio-comment] Re: [virtio] " David Edmondson
2023-08-14 13:28 ` [virtio-comment] " Parav Pandit
2023-08-14 13:56 ` [virtio-comment] " David Edmondson
2023-08-15 4:41 ` [virtio-comment] " Parav Pandit
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=PH0PR12MB54810B9363ACD3E13FE328C5DC15A@PH0PR12MB5481.namprd12.prod.outlook.com \
--to=parav@nvidia.com \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=sdf@google.com \
--cc=shahafs@nvidia.com \
--cc=virtio-comment@lists.oasis-open.org \
--cc=virtio@lists.oasis-open.org \
--cc=willemb@google.com \
--cc=willemdebruijn.kernel@gmail.com \
--cc=xuanzhuo@linux.alibaba.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 read-only IMAP folder(s) and NNTP newsgroup(s).