[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181220123523.bacj7juww2fraqcj@salvia>
Date: Thu, 20 Dec 2018 13:35:23 +0100
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Jakub Kicinski <jakub.kicinski@...ronome.com>
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 Wed, Dec 19, 2018 at 04:26:53PM -0800, Jakub Kicinski wrote:
> 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" :)
OK, this patchset is not updating 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
OK.
[...]
> > 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?
There are two HW offload usecases:
#1 Policy resides in software, CPU host sees initial packets, based on
policy, you place flows into hardware via nf_flow_table infrastructure.
This usecase is fine in your NIC since you assume host CPU can cope
with policy in software for these few initial packets of the flow.
However, switches usually have a small CPU to run control plane
software only. There we _cannot_ use this approach.
#2 Policy resides in hardware. For the usecase of switches with small
CPU, the ACL is deployed in hardware. We use the host CPU to run
control plane configurations only.
This patchset _is not_ related to #1, this patchset _is_ related to #2.
So far, there is infrastructure in Netfilter to do #1, it should be
possible to use it from TC too. In TC, there is infrastructure for #2
which can be reused from Netfilter.
Powered by blists - more mailing lists