[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181219162653.2aeeb15a@cakuba.netronome.com>
Date: Wed, 19 Dec 2018 16:26:53 -0800
From: Jakub Kicinski <jakub.kicinski@...ronome.com>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net,
thomas.lendacky@....com, f.fainelli@...il.com,
ariel.elior@...ium.com, michael.chan@...adcom.com,
santosh@...lsio.com, madalin.bucur@....com,
yisen.zhuang@...wei.com, salil.mehta@...wei.com,
jeffrey.t.kirsher@...el.com, tariqt@...lanox.com,
saeedm@...lanox.com, jiri@...lanox.com, idosch@...lanox.com,
peppe.cavallaro@...com, grygorii.strashko@...com, andrew@...n.ch,
vivien.didelot@...oirfairelinux.com, alexandre.torgue@...com,
joabreu@...opsys.com, linux-net-drivers@...arflare.com,
ganeshgr@...lsio.com, ogerlitz@...lanox.com,
Manish.Chopra@...ium.com, marcelo.leitner@...il.com,
mkubecek@...e.cz, venkatkumar.duvvuru@...adcom.com,
julia.lawall@...6.fr, john.fastabend@...il.com, jhs@...atatu.com,
gerlitz.or@...il.com
Subject: Re: [PATCH net-next,v6 00/12] add flow_rule infrastructure
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?
Powered by blists - more mailing lists