Re: [RFC PATCH 0/7] tc cls_u32 hardware interface
From: Jiri Pirko <jiri@resnulli.us>
Date: 2016-02-02 11:49:46
Mon, Feb 01, 2016 at 02:48:32AM CET, john.fastabend@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, as you described them (e. g. per-rule offload) - we should discuss them on netdev conference. I hope you will be there. I curious about how do you plan to expose the parse graphs get/set ops...
Thanks,
John
---
John Fastabend (7):
net: rework ndo tc op to consume additional qdisc handle parameter
net: rework setup_tc ndo op to consume general tc operand
net: sched: add cls_u32 offload hooks for netdevs
net: add tc offload feature flag
net: tc: helper functions to query action types
net: ixgbe: add minimal parser details for ixgbe
net: ixgbe: add support for tc_u32 offload
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 8 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 2
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 2
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +
drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 11 +
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 3
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 6 -
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 198 ++++++++++++++++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_model.h | 110 ++++++++++++
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 13 +
drivers/net/ethernet/sfc/efx.h | 3
drivers/net/ethernet/sfc/tx.c | 10 +
drivers/net/ethernet/ti/netcp_core.c | 14 +-
include/linux/netdev_features.h | 3
include/linux/netdevice.h | 24 +++
include/net/pkt_cls.h | 33 ++++
include/net/tc_act/tc_gact.h | 14 ++
net/core/ethtool.c | 1
net/sched/cls_u32.c | 73 ++++++++
net/sched/sch_mqprio.c | 8 +
21 files changed, 529 insertions(+), 26 deletions(-)
create mode 100644 drivers/net/ethernet/intel/ixgbe/ixgbe_model.h
--
Signature