From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: [net-next,v5,00/12] add flow_rule infrastructure Date: Thu, 13 Dec 2018 20:54:39 +0100 Message-ID: <20181213195439.dn7wt2mlfoo5dkpw@salvia> References: <20181206224002.5109-1-pablo@netfilter.org> <20181211153519.GA920@strlen.de> <20181211.111420.9962444018507543.davem@davemloft.net> <20181211141735.5ee2e8b7@cakuba.netronome.com> <20181213112315.7ea76799@cakuba.netronome.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Or Gerlitz , David Miller , Florian Westphal , Linux Netdev List , Florian Fainelli , Jiri Pirko , mkubecek@suse.cz, Jamal Hadi Salim To: Jakub Kicinski Return-path: Received: from mail.us.es ([193.147.175.20]:55452 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727707AbeLMTyo (ORCPT ); Thu, 13 Dec 2018 14:54:44 -0500 Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id 06103D165D for ; Thu, 13 Dec 2018 20:54:42 +0100 (CET) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id E8AD7DA4D7 for ; Thu, 13 Dec 2018 20:54:41 +0100 (CET) Content-Disposition: inline In-Reply-To: <20181213112315.7ea76799@cakuba.netronome.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Dec 13, 2018 at 11:23:15AM -0800, Jakub Kicinski wrote: > On Thu, 13 Dec 2018 12:06:39 +0200, Or Gerlitz wrote: > > > Maybe having a side library that could take a ethtool/flower/nft flow > > > and return common IR representation of that flow would be less painful? > > > Drivers could then migrate at its own pace, for new functionality etc. > > > Was that discussed before? I may have lost track of this discussion... > > > > Currently all drivers are ported to use the IR on the tc/flower offload path > > > > End of the day, seems that Jiri and Jakub are good with this and I didn't hear > > any further rejections from other driver folks, so I guess my concerns > > were basically addressed by them. > > I think having the drivers call the IR translation could be a good > compromise instead of having flower always pass down converted flows. > > tc flower -> flower offload object -> setup_tc -> driver -> > -> flow_offload_from_flower() -> driver -> driver's common handling > > This patchset already does that for ethtool: > > ethtool -> ethtool flow -> ethtool_op -> driver -> > -> ethtool_rx_flow_rule_create() -> driver -> driver's common handling > > It feels like a bit of a waste to let the driver patches go, but > perhaps it's a good way to move forward? I think Michal Kubecek mentioned that it would be good if, moving forward, core/ethtool.c calls ethtool_rx_flow_rule_create(), so this is: ethtool -> ethtool flow -> ethtool_rx_flow_rule_create() -> -> ethtool_op -> driver -> driver's common handling In that case, ethtool would match what flower is doing. We can probably offer the flow_rule representation as parameter via ethtool_op indirection, so there is a single ethtool_rx_flow_rule_create() call. Still, this new infrastructure is used by two ethtool drivers, so probably it is too early for this consolidation work.