netdev - Re: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20181029133109.GD31668@localhost>
Date:   Mon, 29 Oct 2018 14:31:09 +0100
From:   Miroslav Lichvar <mlichvar@...hat.com>
To:     "Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
        Richard Cochran <richardcochran@...il.com>
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:
> > -----Original Message-----
> > From: Miroslav Lichvar [mailto:mlichvar@...hat.com]
> > Sent: Friday, October 26, 2018 9:28 AM
> > To: netdev@...r.kernel.org
> > Cc: intel-wired-lan@...ts.osuosl.org; Richard Cochran <richardcochran@...il.com>;
> > Keller, Jacob E <jacob.e.keller@...el.com>; Miroslav Lichvar <mlichvar@...hat.com>
> > Subject: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime
> > 
> > Cc: Richard Cochran <richardcochran@...il.com>
> > Cc: Jacob Keller <jacob.e.keller@...el.com>
> > Signed-off-by: Miroslav Lichvar <mlichvar@...hat.com>

> 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.

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.

> 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.

Thanks,

-- 
Miroslav Lichvar