From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com ([134.134.136.100]:47362 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751656AbeCVWD5 (ORCPT ); Thu, 22 Mar 2018 18:03:57 -0400 Subject: Re: [RFC v3 net-next 14/18] net/sched: Add HW offloading capability to TBS To: Thomas Gleixner , Richard Cochran Cc: 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 References: <20180307011230.24001-1-jesus.sanchez-palencia@intel.com> <20180307011230.24001-15-jesus.sanchez-palencia@intel.com> <20180321150353.5k3kg5h4x5vh5iif@localhost> From: Jesus Sanchez-Palencia Message-ID: <292c3a73-cea8-0fc9-7da5-3cea6bdf0773@intel.com> Date: Thu, 22 Mar 2018 15:01:04 -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, On 03/21/2018 09:18 AM, Thomas Gleixner wrote: > 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. +1 and that is the approach we've taken so far with the qdisc setting "CLOCKID_INVALID" to its internal clockid for the "raw" (non-assisted) hw offload case. thanks, Jesus > > 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 > > > > > >