From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com ([192.55.52.120]:62394 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751595AbeCVX3F (ORCPT ); Thu, 22 Mar 2018 19:29:05 -0400 Subject: Re: [RFC v3 net-next 13/18] net/sched: Introduce the TBS Qdisc To: Thomas Gleixner 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@linaro.org, levi.pearson@harman.com, edumazet@google.com, willemb@google.com, mlichvar@redhat.com References: <20180307011230.24001-1-jesus.sanchez-palencia@intel.com> <20180307011230.24001-14-jesus.sanchez-palencia@intel.com> <7c3f5a9f-cc16-8483-cb77-b5548d46cd5b@intel.com> From: Jesus Sanchez-Palencia Message-ID: <4a61fd66-445d-1273-b63b-0b8989a217b8@intel.com> Date: Thu, 22 Mar 2018 16:26:12 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org List-ID: Hi Thomas, On 03/22/2018 03:11 PM, Thomas Gleixner wrote: (...) >> Having the sorting always enabled requires that a valid static clockid is passed >> to the qdisc. For the hw offload mode, that means that the PHC and one of the >> system clocks must be synchronized since hrtimers do not support dynamic clocks. >> Not all systems do that or want to, and given that we do not want to perform >> crosstimestamping between the packets' clock reference and the qdisc's one, the >> only solution for these systems would be using the raw hw offload mode. > > There are two variants of hardware offload: > > 1) Full hardware offload > > That bypasses the queue completely. You just stick the thing into the > scatter gather buffers. Except when there is no room anymore, then you > have to queue, but it does not make any difference if you queue in FIFO > or in time order. The packets go out in time order anyway. Illustrating your variants with the current qdisc's setup arguments. The above is: - sorting off - offload on (I call it a 'raw' fifo as a reference to the usage of qdisc_enqueue_tail() and qdisc_dequeue_head(), basically.) > > 2) Single packet hardware offload > > What you do here is to schedule a hrtimer a bit earlier than the first > packet tx time and when it fires stick the packet into the hardware and > rearm the timer for the next one. The above is: - sorting on - offload on right? So, are you just opposing to the case where sorting off + offload off is used? (i.e. the scheduled FIFO case) > > The whole point of TSN with hardware support is that you have: > > - Global network time > > and > > - Frequency adjustment of the system time base > > PTP is TAI based and the kernel exposes clock TAI directly through > hrtimers. You don't need dynamic clocks for that. > > You can even use clock MONOTONIC as it basically is just > > TAI - offset> > If the network card uses anything else than TAI or a time stamp with a > strict correlation to TAI for actual TX scheduling then the whole thing is > broken to begin with. Sure, I agree. Thanks, Jesus > > Thanks, > > tglx >