[net-next,v2,0/4] net/sched: cls_api: Support hardware miss to tc action

Message

Paul Blakey Jan. 17, 2023, 8:33 a.m. UTC

Hi,

This series adds support for hardware miss to instruct tc to continue execution
in a specific tc action instance on a filter's action list. The mlx5 driver patch
(besides the refactors) shows its usage instead of using just chain restore.

Currently a filter's action list must be executed all together or
not at all as driver are only able to tell tc to continue executing from a
specific tc chain, and not a specific filter/action.

This is troublesome with regards to action CT, where new connections should
be sent to software (via tc chain restore), and established connections can
be handled in hardware.

Checking for new connections is done when executing the ct action in hardware
(by checking the packet's tuple against known established tuples).
But if there is a packet modification (pedit) action before action CT and the
checked tuple is a new connection, hardware will need to revert the previous
packet modifications before sending it back to software so it can
re-match the same tc filter in software and re-execute its CT action.

The above can happen if the following scenario is offloaded:

$ tc filter add dev dev1 ingress chain 0 proto ip flower \
  ct_state -trk dst_ip 1.1.1.1 \
  action pedit ex munge ip dst 2.2.2.2 \
  action ct \
  action goto chain 1
$ tc filter add dev dev1 ingress chain 1 proto ip flower \
  ct_state +trk+est \
  action mirred egress redirect dev ...
$ tc filter add dev dev1 ingress chain 1 proto ip flower \
  ct_state +trk+new \
  action ct commit \
  action mirred egress redirect dev dev2

$ tc filter add dev dev2 ingress chain 0 proto ip flower \
  action ct \
  action mirred egress redirect dev dev1


A new connection executing the first filter in hardware will first rewrite
the dst ip address to the new ip, then when the ct action is executed,
because this is a new connection, hardware will need to be send this back
to software, on chain 0, to execute the first filter again in software.
The dst ip address needs to be reverted otherwise it won't re-match the old
dst ip address in the first filter.

Because of that, mlx5 driver will reject offloading the above action ct rule.

This series - miss to action, supports partial offload of a filter's action list,
and mainly lets tc software continue processing in the specific action instance
where hardware left off, allowing support for scenarios such as the above.

Changelog:
	Fixed compilation without CONFIG_NET_CLS
	Cover letter re-write

Paul Blakey (6):
  net/sched: cls_api: Support hardware miss to tc action
  net/sched: flower: Move filter handle initialization earlier
  net/sched: flower: Support hardware miss to tc action
  net/mlx5: Refactor tc miss handling to a single function
  net/mlx5e: Rename CHAIN_TO_REG to MAPPED_OBJ_TO_REG
  net/mlx5: TC, Set CT miss to the specific ct action instance

 .../ethernet/mellanox/mlx5/core/en/rep/tc.c   | 225 ++------------
 .../mellanox/mlx5/core/en/tc/sample.c         |   2 +-
 .../ethernet/mellanox/mlx5/core/en/tc_ct.c    |  32 +-
 .../ethernet/mellanox/mlx5/core/en/tc_ct.h    |   2 +
 .../net/ethernet/mellanox/mlx5/core/en_rx.c   |   4 +-
 .../net/ethernet/mellanox/mlx5/core/en_tc.c   | 276 ++++++++++++++++--
 .../net/ethernet/mellanox/mlx5/core/en_tc.h   |  21 +-
 .../net/ethernet/mellanox/mlx5/core/eswitch.h |   2 +
 .../mellanox/mlx5/core/lib/fs_chains.c        |  14 +-
 include/linux/skbuff.h                        |   6 +-
 include/net/flow_offload.h                    |   1 +
 include/net/pkt_cls.h                         |  22 +-
 include/net/sch_generic.h                     |   2 +
 net/openvswitch/flow.c                        |   2 +-
 net/sched/act_api.c                           |   2 +-
 net/sched/cls_api.c                           | 208 ++++++++++++-
 net/sched/cls_flower.c                        |  75 +++--
 17 files changed, 583 insertions(+), 313 deletions(-)