netdev - Re: [Intel-wired-lan] [PATCH next-queue v2 3/3] igc: Add support for PTP getcrosststamp()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <877dqf29mx.fsf@intel.com>
Date:   Fri, 20 Nov 2020 09:58:14 -0800
From:   Vinicius Costa Gomes <vinicius.gomes@...el.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     Miroslav Lichvar <mlichvar@...hat.com>,
        intel-wired-lan@...ts.osuosl.org, andre.guedes@...el.com,
        linux-pci@...r.kernel.org, netdev@...r.kernel.org,
        bhelgaas@...gle.com
Subject: Re: [Intel-wired-lan] [PATCH next-queue v2 3/3] igc: Add support
 for PTP getcrosststamp()

Hi Richard,

Richard Cochran <richardcochran@...il.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