From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from Galois.linutronix.de ([146.0.238.70]:37646 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751423AbeCUQSO (ORCPT ); Wed, 21 Mar 2018 12:18:14 -0400 Date: Wed, 21 Mar 2018 17:18:07 +0100 (CET) From: Thomas Gleixner To: Richard Cochran cc: Jesus Sanchez-Palencia , 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, mlichvar@redhat.com Subject: Re: [RFC v3 net-next 14/18] net/sched: Add HW offloading capability to TBS In-Reply-To: <20180321150353.5k3kg5h4x5vh5iif@localhost> Message-ID: References: <20180307011230.24001-1-jesus.sanchez-palencia@intel.com> <20180307011230.24001-15-jesus.sanchez-palencia@intel.com> <20180321150353.5k3kg5h4x5vh5iif@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: netdev-owner@vger.kernel.org List-ID: On Wed, 21 Mar 2018, Richard Cochran wrote: > On Wed, Mar 21, 2018 at 03:22:11PM +0100, Thomas Gleixner wrote: > > Which clockid will be handed in from the application? The network adapter > > time has no fixed clockid. The only way you can get to it is via a fd based > > posix clock and that does not work at all because the qdisc setup might > > have a different FD than the application which queues packets. > > Duh. That explains it. Please ignore my "why not?" Q in the other thread... :) So in that case you are either bound to rely on the application to use the proper dynamic clock or if we need a sanity check, then you need a cookie of some form which can be retrieved from the posix clock file descriptor and handed in as 'clockid' together with clock_adapter = true. That's doable, but that needs a bit more trickery. A simple unique ID per dynamic posix-clock would be trivial to add, but that would not give you any form of verification whether this ID actually belongs to the network adapter or not. So either you ignore the clockid and rely on the application not being stupid when it says "clock_adpater = true" or you need some extra complexity to build an association of a "clockid" to a network adapter. There is a connection already, via adapter->ptp_clock->devid which is MKDEV(major, index) which is accessible at least at the network driver level, but probably not from networking core. So you'd need to drill a few more holes by adding yet another callback to net_device_ops. I'm not sure if its worth the trouble. If the application hands in bogus timestamps, packets go out at the wrong time or are dropped. That's true whether it uses the proper clock or not. So nothing the kernel should really worry about. For clock_system - REAL/MONO/TAI(sigh) - you surely need a sanity check, but that is independent of the underlying network adapater even in the qdisc assisted HW offload case. Thanks, tglx