-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
Behalf Of Miroslav Lichvar
Sent: Monday, October 29, 2018 6:31 AM
To: Keller, Jacob E <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org; intel-wired-lan@lists.osuosl.org; Richard Cochran
[off-list ref]
Subject: Re: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime

On Fri, Oct 26, 2018 at 04:54:57PM +0000, Keller, Jacob E wrote:

quoted

quoted

-----Original Message-----
From: Miroslav Lichvar [mailto:mlichvar@redhat.com]
Sent: Friday, October 26, 2018 9:28 AM
To: netdev@vger.kernel.org
Cc: intel-wired-lan@lists.osuosl.org; Richard Cochran

[off-list ref];

quoted

quoted

Keller, Jacob E [off-list ref]; Miroslav Lichvar

[off-list ref]

quoted

quoted

Subject: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime

Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Miroslav Lichvar <redacted>

quoted

What about replacing gettime64 with:

static int ixgbe_ptp_gettimex(struct ptp_clock_info *ptp, struct timespec64 *ts)
{
    struct ptp_system_timestamp sts

    ixgbe_ptp_gettimex(ptp, &tst);
    *ts = sts.phc_ts
}

That will work, but it will be slower. With HPET as a clocksource
there would be few microseconds of an extra (symmetric) delay and the
applications would have to assume a larger maximum error.

Right. My intention for this would be that we'd switch from gettime64 to gettime64x going forward, and provide this as a way to avoid having to duplicate logic in drivers while we're transitioning? Thus, new applications should be using the new call if it's available in the driver.

Hmm.
 

I think there could be a flag in ptp_system_timestamp, or a parameter
of gettimex64(), which would enable/disable reading of the system
clock.

quoted

Actually, could that even just be provided by the PTP core if gettime64 isn't

implemented? This way new drivers only have to implement the new interface, and
userspace will just get the old behavior if they use the old call?

Good idea.

Ideally we can find a way that minimizes the overhead for the old call.

Thanks,
Jake

Thanks,

--
Miroslav Lichvar