From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vinicius Costa Gomes Subject: Re: [Intel-wired-lan] [RFC v2 net-next 01/10] net: Add a new socket option for a future transmit time. Date: Wed, 24 Jan 2018 14:46:24 -0800 Message-ID: <87607qzxhb.fsf@intel.com> References: <20180117230621.26074-1-jesus.sanchez-palencia@intel.com> <20180117230621.26074-2-jesus.sanchez-palencia@intel.com> <20180118084227.GL1175@localhost> <877es81d9e.fsf@intel.com> <20180124030436.sukodrg2t3ckazu6@localhost> Mime-Version: 1.0 Content-Type: text/plain Cc: Miroslav Lichvar , Jesus Sanchez-Palencia , netdev@vger.kernel.org, john.stultz@linaro.org, Richard Cochran , jiri@resnulli.us, ivan.briano@intel.com, henrik@austad.us, jhs@mojatatu.com, levi.pearson@harman.com, intel-wired-lan@lists.osuosl.org, xiyou.wangcong@gmail.com, tglx@linutronix.de, anna-maria@linutronix.de To: Richard Cochran Return-path: Received: from mga02.intel.com ([134.134.136.20]:30669 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932800AbeAXWq0 (ORCPT ); Wed, 24 Jan 2018 17:46:26 -0500 In-Reply-To: <20180124030436.sukodrg2t3ckazu6@localhost> Sender: netdev-owner@vger.kernel.org List-ID: Hi Richard, Richard Cochran writes: > On Tue, Jan 23, 2018 at 01:22:37PM -0800, Vinicius Costa Gomes wrote: >> What I think would be the ideal scenario would be if the clockid >> parameter to the TBS Qdisc would not be necessary (if offload was >> enabled), but that's not quite possible right now, because there's no >> support for using the hrtimer infrastructure with dynamic clocks >> (/dev/ptp*). > > We don't need hrtimer for HW offloading. Just enqueue the packets. I > thought we agreed that user space get the ordering correct. In fact, > davem insisted on it, IIRC. About the ordering of packets, From here [1], there are 3 clear points (in my understanding): 1. Re-ordering of TX descriptors on the device queue should/must not happen; 2. Out of order requests are an error; 3. Timestamps in the past are an error; The only robust way that we could think of about keeping the the packets in order for the device queue is re-ordering packets in the Qdisc. We tried to reach out for confirmation [2] of this understanding but didn't receive any word. Even if we reach a decision that the Qdisc should not re-order packets (we wouldn't have any dependency on hrtimers in the offload case, as you pointed out), we still need hrtimers for the software implementation. So, I guess, the problem remains, if it's possible for the user to express a /dev/ptp* clock, what should we do? > > Thanks, > Richard Cheers,