From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesus Sanchez-Palencia Subject: Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc Date: Wed, 11 Apr 2018 16:38:44 -0700 Message-ID: <3d1c27a2-7a21-ab80-e92b-47b415b70548@intel.com> References: <20180307011230.24001-1-jesus.sanchez-palencia@intel.com> <20180307011230.24001-14-jesus.sanchez-palencia@intel.com> <65da0648-b835-a171-3986-2d1ddcb8ea10@intel.com> <2897b562-06e0-0fcc-4fb1-e8c4469c0faa@intel.com> <60799930-56a0-3692-9482-e733d7277152@intel.com> <0369f48c-b48e-ce27-1988-8bc0ec65bf13@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, jhs@mojatatu.com, xiyou.wangcong@gmail.com, jiri@resnulli.us, vinicius.gomes@intel.com, richardcochran@gmail.com, anna-maria@linutronix.de, henrik@austad.us, John Stultz , levi.pearson@harman.com, edumazet@google.com, willemb@google.com, mlichvar@redhat.com To: Thomas Gleixner Return-path: Received: from mga18.intel.com ([134.134.136.126]:62532 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752238AbeDKXmG (ORCPT ); Wed, 11 Apr 2018 19:42:06 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: Hi, On 04/11/2018 01:16 PM, Thomas Gleixner wrote: >>>> Putting it all together, we end up with: >>>> >>>> 1) a new txtime aware qdisc, tbs, to be used per queue. Its cli will look like: >>>> $ tc qdisc add (...) tbs clockid CLOCK_REALTIME delta 150000 offload sorting >>> >>> Why CLOCK_REALTIME? The only interesting time in a TSN network is >>> CLOCK_TAI, really. >> >> REALTIME was just an example here to show that the qdisc has to be configured >> with a clockid parameter. Are you suggesting that instead both of the new qdiscs >> (i.e. tbs and taprio) should always be using CLOCK_TAI implicitly? > > I think so. It's _the_ network time on which everything is based on. Yes, but more on this below. > >>>> 2) a new cmsg-interface for setting a per-packet timestamp that will be used >>>> either as a txtime or as deadline by tbs (and further the NIC driver for the >>>> offlaod case): SCM_TXTIME. >>>> >>>> 3) a new socket option: SO_TXTIME. It will be used to enable the feature for a >>>> socket, and will have as parameters a clockid and a txtime mode (deadline or >>>> explicit), that defines the semantics of the timestamp set on packets using >>>> SCM_TXTIME. >>>> >>>> 4) a new #define DYNAMIC_CLOCKID 15 added to include/uapi/linux/time.h . >>> >>> Can you remind me why we would need that? >> >> So there is a "clockid" that can be used for the full hw offload modes. On this >> case, the txtimes are in reference to the NIC's PTP clock, and, as discussed, we >> can't just use a clockid that was computed from the fd pointing to /dev/ptpX . > > And the NICs PTP clock is CLOCK_TAI, so there should be no reason to have > yet another clock, right? 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. If we are fine with those 'dependencies', then I agree there is no need for another clock. 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. Thanks, Jesus > > Thanks, > > tglx >