On Thu, Dec 20, 2018 at 03:51:00PM +0200, Or Gerlitz wrote: > On Thu, Dec 20, 2018 at 2:35 PM Pablo Neira Ayuso <pa...@netfilter.org> wrote: > > On Wed, Dec 19, 2018 at 04:26:53PM -0800, Jakub Kicinski wrote: > > > > 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. > > confused, isn't this patch set related to connection tracking offloads > on modern NIC HWs?
This patchset is aiming to unify ethtool_rxnfc and tc/cls_flower representation to simplify driver codebase, ie. have a single parser to populate HW IR. My immediate future work is to reuse this new infrastructure to explore #2 for netfilter.
