From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A2F4C54FD0 for ; Fri, 24 Apr 2020 17:41:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3E1BE2075A for ; Fri, 24 Apr 2020 17:41:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729031AbgDXRlb (ORCPT ); Fri, 24 Apr 2020 13:41:31 -0400 Received: from mga06.intel.com ([134.134.136.31]:34773 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727022AbgDXRla (ORCPT ); Fri, 24 Apr 2020 13:41:30 -0400 IronPort-SDR: rzc0LJ4Sq9pbdVUkLzZolbVl0GQ/g+d7MuPuA23Tly9+xnxkJaIPWA4aSOBCFYvulF5PBqMYom dM7xy9lc2nCQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Apr 2020 10:41:29 -0700 IronPort-SDR: f4RRp7WWJttbUvgxw/9UbApYxaL50ZANvd/0c2wTkhy44+grzEtlQjgdh6D3EnkBa2JITfHCMy lZukeMoNSHNg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,311,1583222400"; d="scan'208";a="457998026" Received: from unknown (HELO ellie) ([10.212.255.230]) by fmsmga006.fm.intel.com with ESMTP; 24 Apr 2020 10:41:28 -0700 From: Vinicius Costa Gomes To: Po Liu , "davem\@davemloft.net" , "linux-kernel\@vger.kernel.org" , "netdev\@vger.kernel.org" Cc: Claudiu Manoil , Vladimir Oltean , Alexandru Marginean , "michael.chan\@broadcom.com" , "vishal\@chelsio.com" , "saeedm\@mellanox.com" , "leon\@kernel.org" , "jiri\@mellanox.com" , "idosch\@mellanox.com" , "alexandre.belloni\@bootlin.com" , "UNGLinuxDriver\@microchip.com" , "kuba\@kernel.org" , "jhs\@mojatatu.com" , "xiyou.wangcong\@gmail.com" , "simon.horman\@netronome.com" , "pablo\@netfilter.org" , "moshe\@mellanox.com" , "m-karicheri2\@ti.com" , "andre.guedes\@linux.intel.com" , "stephen\@networkplumber.org" Subject: RE: [EXT] Re: [v3,net-next 1/4] net: qos: introduce a gate control flow action In-Reply-To: References: <20200418011211.31725-5-Po.Liu@nxp.com> <20200422024852.23224-1-Po.Liu@nxp.com> <20200422024852.23224-2-Po.Liu@nxp.com> <878sim2jcs.fsf@intel.com> Date: Fri, 24 Apr 2020 10:41:28 -0700 Message-ID: <874kt83ho7.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Po Liu writes: >> >> One idea that just happened, if you find a way to enable RX timestamping >> and can rely that all packets have a timestamp, the code can simplified a >> lot. You wouldn't need any hrtimers, and deciding to drop or not a packet >> becomes a couple of mathematical operations. Seems worth a thought. > > Thanks for the different ideas. The basic problem is we need to know > now is a close time or open time in action. But I still don't know a > better way than hrtimer to set the flag. That's the point, if you have the timestamp of when the packet arrived, you can calculate if the gate is open and closed at that point. You don't need to know "now", you work only in terms of "skb->tstamp" (supposing that's where the timestamp is stored). In other words, it doesn't matter when the packet arrives at the qdisc action, but when it arrived at the controller, and the actions should be taken based on that time. > >> >> The real question is: if requiring for the driver to support at least software >> RX timestamping is excessive (doesn't seem so to me). > > I understand. > >> >> >> Cheers, >> -- >> Vinicius > > Thanks a lot! > > Br, > Po Liu -- Vinicius