From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH next-queue v2 3/3] igc: Add support for PTP getcrosststamp()
Date: Fri, 20 Nov 2020 09:58:14 -0800 [thread overview]
Message-ID: <877dqf29mx.fsf@intel.com> (raw)
In-Reply-To: <20201120141621.GC7027@hoboy.vegasvil.org>
Hi Richard,
Richard Cochran <richardcochran@gmail.com> writes:
> On Wed, Nov 18, 2020 at 04:22:37PM -0800, Vinicius Costa Gomes wrote:
>
>> Talking with the hardware folks, they recommended using the periodic
>> method, the one shot method was implemented as a debug/evaluation aid.
>
> I'm guessing ...
>
> The HW generates pairs of time stamps, right?
Not exactly.
On the PTM protocol there are four timestamps involved:
- T1, when the NIC sends the Request message;
- T2, when the PCIe root receives the Request message;
- T3, when the PCIe root sends the Response message;
- T4, when the NIC receives the Response message;
The NIC registers expose these values (I am using ' to indicate
timestamps captured on the previous cycle):
- T1 (on this cycle);
- T2 and T2' (on this and on the previous cycle);
- (T4 - T1) and (T4' - T1') (on this and on the previous cycle);
- (T3' - T2') (on the previous cycle).
Yeah, applications would be most interested in a pair (host, device)
timestamps, but as Miroslav said, a third value expressing the
propagation delay from those values could be also useful.
>
> And these land in the device driver by means of an interrupt, right?
Again, not exactly. I have to either poll for a "valid bit" on a status
register or wait for a "fake" (all zeroes source and destination
addresses) ethernet frame to arrive on a specific queue.
Just for information the "fake" packet has different information:
- T1 (on this cycle);
- T2 (on this cycle);
- (T4' - T1') (on the previous cycle);
- (T3 - T2) (on this cycle);
>
> If that is so, then maybe the best way to expose the pair to user
> space is to have a readable character device, like we have for the
> PTP_EXTTS_REQUEST2. The ioctl to enable reporting could also set the
> message rate.
Sounds reasonable.
>
> Although it will be a bit clunky, it looks like we have reserved room
> enough for a second, eight-byte time stamp.
The question is if we want to also expose some of the other values.
Cheers,
--
Vinicius
WARNING: multiple messages have this Message-ID (diff)
From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Richard Cochran <richardcochran@gmail.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>,
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: Fri, 20 Nov 2020 09:58:14 -0800 [thread overview]
Message-ID: <877dqf29mx.fsf@intel.com> (raw)
In-Reply-To: <20201120141621.GC7027@hoboy.vegasvil.org>
Hi Richard,
Richard Cochran <richardcochran@gmail.com> writes:
> On Wed, Nov 18, 2020 at 04:22:37PM -0800, Vinicius Costa Gomes wrote:
>
>> Talking with the hardware folks, they recommended using the periodic
>> method, the one shot method was implemented as a debug/evaluation aid.
>
> I'm guessing ...
>
> The HW generates pairs of time stamps, right?
Not exactly.
On the PTM protocol there are four timestamps involved:
- T1, when the NIC sends the Request message;
- T2, when the PCIe root receives the Request message;
- T3, when the PCIe root sends the Response message;
- T4, when the NIC receives the Response message;
The NIC registers expose these values (I am using ' to indicate
timestamps captured on the previous cycle):
- T1 (on this cycle);
- T2 and T2' (on this and on the previous cycle);
- (T4 - T1) and (T4' - T1') (on this and on the previous cycle);
- (T3' - T2') (on the previous cycle).
Yeah, applications would be most interested in a pair (host, device)
timestamps, but as Miroslav said, a third value expressing the
propagation delay from those values could be also useful.
>
> And these land in the device driver by means of an interrupt, right?
Again, not exactly. I have to either poll for a "valid bit" on a status
register or wait for a "fake" (all zeroes source and destination
addresses) ethernet frame to arrive on a specific queue.
Just for information the "fake" packet has different information:
- T1 (on this cycle);
- T2 (on this cycle);
- (T4' - T1') (on the previous cycle);
- (T3 - T2) (on this cycle);
>
> If that is so, then maybe the best way to expose the pair to user
> space is to have a readable character device, like we have for the
> PTP_EXTTS_REQUEST2. The ioctl to enable reporting could also set the
> message rate.
Sounds reasonable.
>
> Although it will be a bit clunky, it looks like we have reserved room
> enough for a second, eight-byte time stamp.
The question is if we want to also expose some of the other values.
Cheers,
--
Vinicius
next prev parent reply other threads:[~2020-11-20 17:58 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 6:10 [Intel-wired-lan] [PATCH next-queue v2 0/3] igc: Add support for PCIe PTM Vinicius Costa Gomes
2020-11-10 6:10 ` Vinicius Costa Gomes
2020-11-10 6:10 ` [Intel-wired-lan] [PATCH next-queue v2 1/3] Revert "PCI: Make pci_enable_ptm() private" Vinicius Costa Gomes
2020-11-10 6:10 ` Vinicius Costa Gomes
2020-11-10 6:10 ` [Intel-wired-lan] [PATCH next-queue v2 2/3] igc: Enable PCIe PTM Vinicius Costa Gomes
2020-11-10 6:10 ` Vinicius Costa Gomes
2020-11-10 6:10 ` [Intel-wired-lan] [PATCH next-queue v2 3/3] igc: Add support for PTP getcrosststamp() Vinicius Costa Gomes
2020-11-10 6:10 ` Vinicius Costa Gomes
2020-11-10 18:07 ` [Intel-wired-lan] " Miroslav Lichvar
2020-11-10 18:07 ` Miroslav Lichvar
2020-11-10 19:06 ` Vinicius Costa Gomes
2020-11-10 19:06 ` Vinicius Costa Gomes
2020-11-11 9:33 ` Miroslav Lichvar
2020-11-11 9:33 ` Miroslav Lichvar
2020-11-11 22:23 ` Vinicius Costa Gomes
2020-11-11 22:23 ` Vinicius Costa Gomes
2020-11-12 9:32 ` Miroslav Lichvar
2020-11-12 9:32 ` Miroslav Lichvar
2020-11-12 23:46 ` Vinicius Costa Gomes
2020-11-12 23:46 ` Vinicius Costa Gomes
2020-11-13 3:24 ` Richard Cochran
2020-11-13 3:24 ` Richard Cochran
2020-11-13 19:10 ` Vinicius Costa Gomes
2020-11-13 19:10 ` Vinicius Costa Gomes
2020-11-14 2:57 ` Richard Cochran
2020-11-14 2:57 ` Richard Cochran
2020-11-17 1:06 ` Vinicius Costa Gomes
2020-11-17 1:06 ` Vinicius Costa Gomes
2020-11-17 1:49 ` Richard Cochran
2020-11-17 1:49 ` Richard Cochran
2020-11-18 1:21 ` Vinicius Costa Gomes
2020-11-18 1:21 ` Vinicius Costa Gomes
2020-11-18 12:54 ` Richard Cochran
2020-11-18 12:54 ` Richard Cochran
2020-11-19 0:22 ` Vinicius Costa Gomes
2020-11-19 0:22 ` Vinicius Costa Gomes
2020-11-20 14:16 ` Richard Cochran
2020-11-20 14:16 ` Richard Cochran
2020-11-20 17:58 ` Vinicius Costa Gomes [this message]
2020-11-20 17:58 ` Vinicius Costa Gomes
2021-03-22 15:36 ` Vinicius Costa Gomes
2021-03-22 15:36 ` Vinicius Costa Gomes
2021-03-23 4:17 ` Richard Cochran
2021-03-23 4:17 ` Richard Cochran
2020-11-18 15:55 ` Jakub Kicinski
2020-11-18 15:55 ` Jakub Kicinski
2020-11-20 19:07 ` Vinicius Costa Gomes
2020-11-20 19:07 ` Vinicius Costa Gomes
2020-11-12 0:38 ` Vinicius Costa Gomes
2020-11-12 0:38 ` Vinicius Costa Gomes
2021-03-22 15:47 ` 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=877dqf29mx.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=intel-wired-lan@osuosl.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: link
Be 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.