Re: [RFC PATCH 0/7] tc cls_u32 hardware interface

On 16-02-02 03:49 AM, Jiri Pirko wrote:

Mon, Feb 01, 2016 at 02:48:32AM CET, john.fastabend@gmail.com wrote:

quoted

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.