On 16-02-02 03:49 AM, Jiri Pirko wrote: > Mon, Feb 01, 2016 at 02:48:32AM CET, john.fastab...@gmail.com wrote: >> I was waiting for net-next to open to submit this but it seems like >> a good idea to get an RFC out there for folks to start looking over. >> >> 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. >> I am working on similar support for the other Intel devices now >> as well namely i40e and fm10k. >> >> Also in the future work bin 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. >> >> Note this series is on a slightly behind net-next stack I think it >> should apply to the latest but I haven't updated the series for >> awhile I'll do that soon I was sort of waiting for net-next to >> open to do this. >> >> Any comments/feedback appreciated. > > I like this patchset. I gave it a quick peek and I it looks to me like > the correct way to go. There are couple of things needed to be decided
Great. , > as you described them (e. g. per-rule offload) - we should discuss them > on netdev conference. I hope you will be there. > I'll be at the conference so we can discuss it there. Although even without the per-rule flow this set is useful. Like I noted I view that as an optimization and its much more useful on a NIC where host traffic is the norm vs a switch where host traffic is most likely the exception. > I curious about how do you plan to expose the parse graphs get/set ops... The current stack of patches I have on my dev box use a new netlink handler. ethtool could work as well but my preference is netlink in this case.
