From mboxrd@z Thu Jan 1 00:00:00 1970 From: Miroslav Lichvar Subject: Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc Date: Thu, 12 Apr 2018 17:19:26 +0200 Message-ID: <20180412151926.GJ31379@localhost> References: <2897b562-06e0-0fcc-4fb1-e8c4469c0faa@intel.com> <60799930-56a0-3692-9482-e733d7277152@intel.com> <0369f48c-b48e-ce27-1988-8bc0ec65bf13@intel.com> <3d1c27a2-7a21-ab80-e92b-47b415b70548@intel.com> <20180412150349.3dgkgqx4ged6t4ng@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jesus Sanchez-Palencia , Thomas Gleixner , netdev@vger.kernel.org, jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us, vinicius.gomes@intel.com, anna-maria@linutronix.de, henrik@austad.us, John Stultz , levi.pearson@harman.com, edumazet@google.com, willemb@google.com To: Richard Cochran Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:42168 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753391AbeDLPT1 (ORCPT ); Thu, 12 Apr 2018 11:19:27 -0400 Content-Disposition: inline In-Reply-To: <20180412150349.3dgkgqx4ged6t4ng@localhost> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Apr 12, 2018 at 08:03:49AM -0700, Richard Cochran wrote: > On Wed, Apr 11, 2018 at 04:38:44PM -0700, Jesus Sanchez-Palencia wrote: > > Just breaking this down a bit, yes, TAI is the network time base, and the NICs > > PTP clock use that because PTP is (commonly) based on TAI. After the PHCs have > > been synchronized over the network (e.g. with ptp4l), my understanding is that > > if applications want to use the clockid_t CLOCK_TAI as a network clock reference > > it's required that something (i.e. phc2sys) is synchronizing the PHCs and the > > system clock, and also that something calls adjtime to apply the TAI vs UTC > > offset to CLOCK_TAI. > > Yes. I haven't seen any distro that sets the TAI-UTC offset after > boot, nor are there any user space tools for this. The kernel is > ready, though. FWIW, the default NTP configuration in Fedora sets the kernel TAI-UTC offset. > > I was thinking about the full offload use-cases, thus when no scheduling is > > happening inside the qdiscs. Applications could just read the time from the PHC > > clocks directly without having to rely on any of the above. On this case, > > userspace would use DYNAMIC_CLOCK just to flag that this is the case, but I must > > admit it's not clear to me how common of a use-case that is, or even if it makes > > sense. > > 1588 allows only two timescales, TAI and ARB-itrary. Although it > doesn't make too much sense to use ARB, still people will do strange > things. Probably some people use UTC. I am not advocating supporting > alternate timescales, just pointing out the possibility. There is also the possibility that the NIC clock is not synchronized to anything. For synchronization of the system clock it's easier to leave it free running and only track its phase/frequency offset to allow conversion between the PHC and system time. -- Miroslav Lichvar