Thu, Nov 29, 2018 at 04:47:07PM CET, john.fastab...@gmail.com wrote: >On 11/28/18 6:22 PM, Pablo Neira Ayuso wrote: >> Hi, >> >> This patchset is another iteration to introduce an in-kernel intermediate >> representation (IR) to express ACL hardware offloads [1] [2] [3]. >> > >Hi, > >Also wanted to add. In an earlier thread it was mentioned this could be >used for other offload rule infrastructures specifically u32 was >mentioned. I don't think this is actually possible on the flow_rule >side. This set uses basically an enum based key system where enums >such as FLOW_DISSECTOR_KEY_* identify the field in the packet. For >every field we want to match a new key is needed. But the u32 classifier >defines fields using offset/mask and a parse graph. They do not seem >compatible to me so in the end this unifies ethtool and flower only. >Did I get this right? > >So would it be better to simply map ethtool onto flower vs defining >a new one? Patch 1 seems to be pretty light-weight so maybe rather >than calling it a new IR we just need some helper routines for >drivers to work with.
You don't really want to create TC internal structures in order to offload ethtool stuff. So you need something generic and subsystem agnostic so you can use it by both (and possibly more). And that is exactly what this patchset is doing. U32 is on the side. You still offload u32 via existing structs. No change there. Nobody is pushing u32 to use any other structs. If later on (I don't see it likely) there will be another subsystem using u32-like structures, we can find the generic structs for that too. > >Probably a more detailed cover letter explaining motivation >and any future work would help (me at least) understand the direction. >I see netfilter offload was mentioned at one point so maybe that is >the motivation that makes it more clear why flower API today is >insufficient. Mostly curious at this point I see Jiri and Florian >both reviewed it already. > >Thanks, >John
