On Fri, Nov 16, 2018 at 3:43 AM Pablo Neira Ayuso <pa...@netfilter.org> wrote: > This patchset introduces a kernel intermediate representation (IR) to > express ACL hardware offloads, this is heavily based on the existing > flow dissector infrastructure and the TC actions. This IR can be used by > different frontend ACL interfaces such as ethtool_rxnfc and tc to
any reason to keep aRFS out? > represent ACL hardware offloads. Main goal is to simplify the > development of ACL hardware offloads for the existing frontend > interfaces, the idea is that driver developers do not need to add one > specific parser for each ACL frontend, instead each frontend can just > generate this flow_rule IR and pass it to drivers to populate the > hardware IR. yeah, but we are adding one more chain (IR), today we have kernel frontend U/API X --> kernel parser Y --> driver --> HW API kernel frontend U/API Z --> kernel parser W --> driver --> HW API and we move to kernel frontend U/API X --> kernel parser Y --> IR --> driver --> HW API kernel frontend U/API Z --> kernel parser W --> IR --> driver --> HW API So instead of Y --> HW W --> HW we have IR --> HW while loosing the TC semantics and spirit in the drivers. We could have normalize all the U/APIs to use the flow dissectors and the TC actions and then have the drivers to deal with TC only. IMHO flow dissectors and TC actions are the right approach to deal with ACLs HW offloading. They properly reflect how ACLs work in modern HW pipelines. > > . ethtool_rxnfc tc > | (ioctl) (netlink) > | | | translate native > Frontend | | | interface representation > | | | to flow_rule IR > | | | > . \/ \/ > . flow_rule IR > | | > Drivers | | parsing of flow_rule IR > | | to populate hardware IR > | \/ > . hardware IR (driver) > > For design and implementation details, please have a look at: > > https://lwn.net/Articles/766695/ I will further look next week, but as this is not marked as RFC (and not with net-next on the title), can we consider this still a discussion and not final/review? > As an example, with this patchset, it should be possible to simplify the > existing net/qede driver which already has two parsers to populate the > hardware IR, one for ethtool_rxnfc interface and another for tc. I think it would be fair to ask for one such driver porting to see the impact/benefit. Or.
