From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Briano Subject: Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc Date: Wed, 11 Apr 2018 13:31:31 -0700 Message-ID: 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 , Jesus Sanchez-Palencia Return-path: Received: from mga03.intel.com ([134.134.136.65]:62384 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756239AbeDKUbd (ORCPT ); Wed, 11 Apr 2018 16:31:33 -0400 In-Reply-To: Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 04/11/2018 01:16 PM, Thomas Gleixner wrote: > On Tue, 10 Apr 2018, Jesus Sanchez-Palencia wrote: >>>> This will be provided by tbs if the socket which is transmitting packets is >>>> configured for deadline mode. >>> >>> You don't want the socket to decide that. The qdisc into which a socket >>> feeds defines the mode and the qdisc rejects requests with the wrong mode. >>> >>> Making a qdisc doing both and let the user decide what he wants it to be is >>> not really going to fly. Especially if you have different users which want >>> a different mode. It's clearly distinct functionality. >> >> >> Ok, so just to make sure I got this right, are you suggesting that both the >> 'tbs' qdisc *and* the socket (i.e. through SO_TXTIME) should have a config >> parameter for specifying the txtime mode? This way if there is a mismatch, >> packets from that socket are rejected by the qdisc. > > Correct. The same is true if you try to set SO_TXTIME for something which > is just routing regular traffic. > >> (...) >>> >>>> Another question for this mode (but perhaps that applies to both modes) is, what >>>> if the qdisc misses the deadline for *any* reason? I'm assuming it should drop >>>> the packet during dequeue. >>> >>> There the question is how user space is notified about that issue. The >>> application which queued the packet on time does rightfully assume that >>> it's going to be on the wire on time. >>> >>> This is a violation of the overall scheduling plan, so you need to have >>> a sane design to handle that. >> >> In addition to the qdisc stats, we could look into using the socket's error >> queue to notify the application about that. > > Makes sense. > >>>> 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. > >>>> 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? > Most likely, though you can technically have a different time domain that is not based on TAI. > Thanks, > > tglx >