> -----Original Message----- > From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On > Behalf Of Miroslav Lichvar > Sent: Monday, October 29, 2018 6:31 AM > To: Keller, Jacob E <jacob.e.kel...@intel.com> > Cc: netdev@vger.kernel.org; intel-wired-...@lists.osuosl.org; Richard Cochran > <richardcoch...@gmail.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:mlich...@redhat.com] > > > Sent: Friday, October 26, 2018 9:28 AM > > > To: netdev@vger.kernel.org > > > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran > <richardcoch...@gmail.com>; > > > Keller, Jacob E <jacob.e.kel...@intel.com>; Miroslav Lichvar > <mlich...@redhat.com> > > > Subject: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime > > > > > > Cc: Richard Cochran <richardcoch...@gmail.com> > > > Cc: Jacob Keller <jacob.e.kel...@intel.com> > > > Signed-off-by: Miroslav Lichvar <mlich...@redhat.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. >
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. > > > 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
