From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski Subject: Re: [PATCH net-next,v6 00/12] add flow_rule infrastructure Date: Wed, 19 Dec 2018 16:26:53 -0800 Message-ID: <20181219162653.2aeeb15a@cakuba.netronome.com> References: <20181214181205.28812-1-pablo@netfilter.org> <20181217173929.024ab742@cakuba.netronome.com> <20181218195705.r6v7n4gaponpmeak@salvia> <20181219115703.51253f51@cakuba.netronome.com> <20181220000313.cursjruvzknstlzd@salvia> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, 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, 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, mkubecek@suse.cz, venkatkumar.duvvuru@broadcom.com, julia.lawall@lip6.fr, john.fastabend@gmail.com, jhs@mojatatu.com, gerlitz.or@gmail.com To: Pablo Neira Ayuso Return-path: Received: from mail-qt1-f194.google.com ([209.85.160.194]:37140 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727317AbeLTA1C (ORCPT ); Wed, 19 Dec 2018 19:27:02 -0500 Received: by mail-qt1-f194.google.com with SMTP id t33so21651953qtt.4 for ; Wed, 19 Dec 2018 16:27:01 -0800 (PST) In-Reply-To: <20181220000313.cursjruvzknstlzd@salvia> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 20 Dec 2018 01:03:13 +0100, Pablo Neira Ayuso wrote: > On Wed, Dec 19, 2018 at 11:57:03AM -0800, Jakub Kicinski wrote: > > > Anyway, the problem that this patchset addresses _already exists_ with > > > ethtool_rxnfc and cls_flower in place, it would be good to fix it now. > > > > That's not the point of contention. > > What is your alternative plan to unify driver codebase for > ethtool_rx_flow_spec and tc/cls_flower to offload ACL from the ingress > path? The point of contention for me is the "reuse of ndo_setup_tc" :) I haven't played with your IR, but it looks fairly close to the flower dissector based thing, so it's probably fine > > Did you consider things like tunnels and bonds? There are a lot of > > problems which have been solved for TC offloads, if you create a > > separate subsystem offload you'll have to repeat all that work. > > Did I repeat any work to unify ethtool_rx_flow_spec and tc/cls_flower? > No :-). I spinned over the existing work and delivered an incremental > update. Ethtool exists, so you don't have to teach the driver about it. nft offload does not, yet, exist in upstream drivers AFAIK. Besides, if ethtool n-tuples were rich and supported complex use cases we wouldn't have TC flower offloads, so it's not apples to apples ;) > > I'm not suggesting we replace netfilter with TC. I'm suggesting we > > replace nf_flow_offload table with something that fits into TC. > > > > You're not going to offload entire netfilter. You want to offload > > simplistic flows through the nf_flow_table. What I'm saying, is add a > > equivalent of that table into TC. Make user space "link" netfilter to > > that. > > This patchset is not related to nf_flow_table infrastructure. Let's not let the elephant back into the room, please :) > From what I'm reading, you assume we can use nf_flow_table everywhere, > which is probably true if you assume people use your NICs. However, > there is a class of hardware where CPU is extremely smallish to cope > with flows in software, where dataplane is almost entirely offloaded > to hardware. In that scenario, nf_flow_table cannot be used. I'm confused, could you rephrase? How does you work help such devices? How is tc not suitable for them?