From: Miroslav Lichvar <mlichvar@redhat.com>
To: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, andre.guedes@intel.com,
linux-pci@vger.kernel.org, netdev@vger.kernel.org,
bhelgaas@google.com
Subject: Re: [Intel-wired-lan] [PATCH next-queue v2 3/3] igc: Add support for PTP getcrosststamp()
Date: Wed, 11 Nov 2020 10:33:46 +0100 [thread overview]
Message-ID: <20201111093346.GE1559650@localhost> (raw)
In-Reply-To: <871rh19gm8.fsf@intel.com>
On Tue, Nov 10, 2020 at 11:06:07AM -0800, Vinicius Costa Gomes wrote:
> Miroslav Lichvar <mlichvar@redhat.com> writes:
> > I suspect the estimate would be valid only when the NIC is connected
> > directly to the PTM root (PCI root complex). Is it possible to get the
> > timestamps or delay from PTM-capable switches on the path between CPU
> > and NIC? Also, how frequent can be the PTM dialogs? Could they be
> > performed synchronously in the ioctl?
>
> Reading the PTM specs, it could work over PCIe switches (if they also
> support PTM).
I saw some "implementation specific means" mentioned in the spec, so
I'm not sure what and how exactly it works with the existing CPUs,
NICs and PCIe switches. But even if the reported delay was valid only
for directly connected NICs, I think that could still be useful as
long as the user/application can figure out whether that is the case.
> The NIC I have supports PTM cycles from every ~1ms to ~512ms, and from
> my tests it wants to be kept running "in background" always, i.e. set
> the cycles to run, and only report the data when necessary. Trying to
> only enable the cycles "on demand" was unreliable.
I see. It does makes sense if the clocks need to be are synchronized.
For the case of this ioctl, I think it would be better if it we could
just collect the measurements and leave the clocks free running.
> (so for the _EXTENDED case, I would need to accumulate multiple values
> in the driver, and report them later, a bit annoying, but not
> impossible)
I think you could simply repeat the sample in the output up to the
requested number.
I suspect a bigger issue, for both the PRECISE and EXTENDED variants,
is that it would return old data. I'm not sure if the existing
applications are ready to deal with that. With high clock update
rates, a delay of 50 milliseconds could cause an instability. You can
try phc2sys -R 50 and see if it stays stable.
The minimum 1ms cycle you mentioned would probably work better for the
applications.
--
Miroslav Lichvar
next prev parent reply other threads:[~2020-11-11 9:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 6:10 [PATCH next-queue v2 0/3] igc: Add support for PCIe PTM Vinicius Costa Gomes
2020-11-10 6:10 ` [PATCH next-queue v2 1/3] Revert "PCI: Make pci_enable_ptm() private" Vinicius Costa Gomes
2020-11-10 6:10 ` [PATCH next-queue v2 2/3] igc: Enable PCIe PTM Vinicius Costa Gomes
2020-11-10 6:10 ` [PATCH next-queue v2 3/3] igc: Add support for PTP getcrosststamp() Vinicius Costa Gomes
2020-11-10 18:07 ` [Intel-wired-lan] " Miroslav Lichvar
2020-11-10 19:06 ` Vinicius Costa Gomes
2020-11-11 9:33 ` Miroslav Lichvar [this message]
2020-11-11 22:23 ` Vinicius Costa Gomes
2020-11-12 9:32 ` Miroslav Lichvar
2020-11-12 23:46 ` Vinicius Costa Gomes
2020-11-13 3:24 ` Richard Cochran
2020-11-13 19:10 ` Vinicius Costa Gomes
2020-11-14 2:57 ` Richard Cochran
2020-11-17 1:06 ` Vinicius Costa Gomes
2020-11-17 1:49 ` Richard Cochran
2020-11-18 1:21 ` Vinicius Costa Gomes
2020-11-18 12:54 ` Richard Cochran
2020-11-19 0:22 ` Vinicius Costa Gomes
2020-11-20 14:16 ` Richard Cochran
2020-11-20 17:58 ` Vinicius Costa Gomes
2021-03-22 15:36 ` Vinicius Costa Gomes
2021-03-23 4:17 ` Richard Cochran
2020-11-18 15:55 ` Jakub Kicinski
2020-11-20 19:07 ` Vinicius Costa Gomes
2020-11-12 0:38 ` Vinicius Costa Gomes
2021-03-22 15:47 ` Vinicius Costa Gomes
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=20201111093346.GE1559650@localhost \
--to=mlichvar@redhat.com \
--cc=andre.guedes@intel.com \
--cc=bhelgaas@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vinicius.gomes@intel.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).