Wed, Feb 03, 2016 at 10:27:32AM CET, john.fastab...@gmail.com wrote: >This extends the setup_tc framework so it can support more than just >the mqprio offload and push other classifiers and qdiscs into the >hardware. The series here targets the u32 classifier and ixgbe >driver. I worked out the u32 classifier because it is protocol >oblivious and aligns with multiple hardware devices I have access >to. I did an initial implementation on ixgbe because (a) I have one >in my box (b) its a stable driver and (c) it is relatively simple >compared to the other devices I have here but still has enough >flexibility to exercise the features of cls_u32. > >I intentionally limited the scope of this series to the basic >feature set. Specifically this uses a 'big hammer' feature bit >to do the offload or not. If the bit is set you get offloaded rules >if it is not then rules will not be offloaded. If we can agree on >this patch series there are some more patches on my queue we can >talk about to make the offload decision per rule using flags similar >to how we do l2 mac updates. Additionally the error strategy can >be improved to be hard aborting, log and continue, etc. I think >these are nice to have improvements but shouldn't block this series. > >Also by adding get_parse_graph and set_parse_graph attributes as >in my previous flow_api work we can build programmable devices >and programmatically learn when rules can or can not be loaded >into the hardware. Again future work. > >Any comments/feedback appreciated.
I like this being thin and elegant solution. However, ~2 years ago when I pushed openvswitch kernel datapath offload patchset, people were yelling at me that it is not generic enough solution, that tc has to be able to use the api (Jamal :)), nftables as well. Now this patch is making offload strictly tc-based and nobody seems to care :) I do. I think that we might try to find some generic middle layer. Let's discuss this more in person next week. Thanks!
