From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend Subject: Re: [PATCH net-next,v4 00/12] add flow_rule infrastructure Date: Thu, 29 Nov 2018 07:47:07 -0800 Message-ID: References: <20181129022231.2740-1-pablo@netfilter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: davem@davemloft.net, thomas.lendacky@amd.com, f.fainelli@gmail.com, ariel.elior@cavium.com, michael.chan@broadcom.com, santosh@chelsio.com, madalin.bucur@nxp.com, yisen.zhuang@huawei.com, salil.mehta@huawei.com, jeffrey.t.kirsher@intel.com, tariqt@mellanox.com, saeedm@mellanox.com, jiri@mellanox.com, idosch@mellanox.com, jakub.kicinski@netronome.com, peppe.cavallaro@st.com, grygorii.strashko@ti.com, andrew@lunn.ch, vivien.didelot@savoirfairelinux.com, alexandre.torgue@st.com, joabreu@synopsys.com, linux-net-drivers@solarflare.com, ganeshgr@chelsio.com, ogerlitz@mellanox.com, Manish.Chopra@cavium.com, marcelo.leitner@gmail.com To: Pablo Neira Ayuso , netdev@vger.kernel.org Return-path: Received: from mail-it1-f195.google.com ([209.85.166.195]:53603 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728363AbeK3CxY (ORCPT ); Thu, 29 Nov 2018 21:53:24 -0500 Received: by mail-it1-f195.google.com with SMTP id g85so4247560ita.3 for ; Thu, 29 Nov 2018 07:47:37 -0800 (PST) In-Reply-To: <20181129022231.2740-1-pablo@netfilter.org> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 11/28/18 6:22 PM, Pablo Neira Ayuso wrote: > Hi, > > This patchset is another iteration to introduce an in-kernel intermediate > representation (IR) to express ACL hardware offloads [1] [2] [3]. > Hi, Also wanted to add. In an earlier thread it was mentioned this could be used for other offload rule infrastructures specifically u32 was mentioned. I don't think this is actually possible on the flow_rule side. This set uses basically an enum based key system where enums such as FLOW_DISSECTOR_KEY_* identify the field in the packet. For every field we want to match a new key is needed. But the u32 classifier defines fields using offset/mask and a parse graph. They do not seem compatible to me so in the end this unifies ethtool and flower only. Did I get this right? So would it be better to simply map ethtool onto flower vs defining a new one? Patch 1 seems to be pretty light-weight so maybe rather than calling it a new IR we just need some helper routines for drivers to work with. Probably a more detailed cover letter explaining motivation and any future work would help (me at least) understand the direction. I see netfilter offload was mentioned at one point so maybe that is the motivation that makes it more clear why flower API today is insufficient. Mostly curious at this point I see Jiri and Florian both reviewed it already. Thanks, John