From: "Keller, Jacob E" <jacob.e.keller@intel.com> To: Miroslav Lichvar <mlichvar@redhat.com> Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>, Richard Cochran <richardcochran@gmail.com> Subject: RE: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime Date: Mon, 29 Oct 2018 16:02:57 +0000 [thread overview] Message-ID: <02874ECE860811409154E81DA85FBB5884CFF78A@ORSMSX115.amr.corp.intel.com> (raw) In-Reply-To: <20181029133109.GD31668@localhost> > -----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 > <richardcochran@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: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 > <richardcochran@gmail.com>; > > > Keller, Jacob E <jacob.e.keller@intel.com>; Miroslav Lichvar > <mlichvar@redhat.com> > > > 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 <mlichvar@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
WARNING: multiple messages have this Message-ID (diff)
From: Keller, Jacob E <jacob.e.keller@intel.com> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime Date: Mon, 29 Oct 2018 16:02:57 +0000 [thread overview] Message-ID: <02874ECE860811409154E81DA85FBB5884CFF78A@ORSMSX115.amr.corp.intel.com> (raw) In-Reply-To: <20181029133109.GD31668@localhost> > -----Original Message----- > From: netdev-owner at vger.kernel.org [mailto:netdev-owner at 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 at vger.kernel.org; intel-wired-lan at lists.osuosl.org; Richard Cochran > <richardcochran@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:mlichvar at redhat.com] > > > Sent: Friday, October 26, 2018 9:28 AM > > > To: netdev at vger.kernel.org > > > Cc: intel-wired-lan at lists.osuosl.org; Richard Cochran > <richardcochran@gmail.com>; > > > Keller, Jacob E <jacob.e.keller@intel.com>; Miroslav Lichvar > <mlichvar@redhat.com> > > > 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 <mlichvar@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
next prev parent reply other threads:[~2018-10-30 0:52 UTC|newest] Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-26 16:27 [RFC PATCH 0/4] More accurate PHC<->system clock synchronization Miroslav Lichvar 2018-10-26 16:27 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-26 16:27 ` [RFC PATCH 1/4] ptp: add PTP_SYS_OFFSET_EXTENDED ioctl Miroslav Lichvar 2018-10-26 16:27 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-26 22:16 ` Vinicius Costa Gomes 2018-10-26 22:16 ` Vinicius Costa Gomes 2018-10-29 12:52 ` Miroslav Lichvar 2018-10-29 12:52 ` Miroslav Lichvar 2018-10-31 2:23 ` Richard Cochran 2018-10-31 2:23 ` [Intel-wired-lan] " Richard Cochran 2018-10-31 3:01 ` Richard Cochran 2018-10-31 3:01 ` [Intel-wired-lan] " Richard Cochran 2018-10-26 16:27 ` [RFC PATCH 2/4] e1000e: add support for extended PHC gettime Miroslav Lichvar 2018-10-26 16:27 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-26 16:27 ` [RFC PATCH 3/4] igb: " Miroslav Lichvar 2018-10-26 16:27 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-31 2:29 ` Richard Cochran 2018-10-31 2:29 ` [Intel-wired-lan] " Richard Cochran 2018-10-31 9:39 ` Miroslav Lichvar 2018-10-31 9:39 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-31 16:56 ` Keller, Jacob E 2018-10-31 16:56 ` [Intel-wired-lan] " Keller, Jacob E 2018-10-26 16:27 ` [RFC PATCH 4/4] ixgbe: " Miroslav Lichvar 2018-10-26 16:27 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-26 16:54 ` Keller, Jacob E 2018-10-26 16:54 ` [Intel-wired-lan] " Keller, Jacob E 2018-10-29 13:31 ` Miroslav Lichvar 2018-10-29 13:31 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-29 16:02 ` Keller, Jacob E [this message] 2018-10-29 16:02 ` Keller, Jacob E 2018-10-31 14:40 ` Richard Cochran 2018-10-31 14:40 ` [Intel-wired-lan] " Richard Cochran 2018-10-31 14:49 ` Miroslav Lichvar 2018-10-31 14:49 ` [Intel-wired-lan] " Miroslav Lichvar 2018-10-31 21:16 ` Richard Cochran 2018-10-31 21:16 ` [Intel-wired-lan] " Richard Cochran 2018-10-31 22:08 ` Keller, Jacob E 2018-10-31 22:08 ` [Intel-wired-lan] " Keller, Jacob E 2018-10-31 16:55 ` Keller, Jacob E 2018-10-31 16:55 ` [Intel-wired-lan] " Keller, Jacob E 2018-10-26 16:40 ` [RFC PATCH 0/4] More accurate PHC<->system clock synchronization Keller, Jacob E 2018-10-26 16:40 ` [Intel-wired-lan] " Keller, Jacob E 2018-10-26 16:51 ` Keller, Jacob E 2018-10-26 16:51 ` [Intel-wired-lan] " Keller, Jacob E 2018-10-31 2:25 ` Richard Cochran 2018-10-31 2:25 ` [Intel-wired-lan] " Richard Cochran
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=02874ECE860811409154E81DA85FBB5884CFF78A@ORSMSX115.amr.corp.intel.com \ --to=jacob.e.keller@intel.com \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=mlichvar@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=richardcochran@gmail.com \ /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: linkBe 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.