| Message ID | 1581847296-19194-1-git-send-email-paulb@mellanox.com |
|---|---|
| Headers | show |
| Series | Handle multi chain hardware misses | expand |
On Sun, 2020-02-16 at 12:01 +0200, Paul Blakey wrote: > Hi David/Jakub/Saeed, > > TC multi chain configuration can cause offloaded tc chains to miss in > hardware after jumping to some chain. In such cases the software > should > continue from the chain that was missed in hardware, as the hardware > may have > manipulated the packet and updated some counters. > [...] > Note that miss path handling of multi-chain rules is a required > infrastructure > for connection tracking hardware offload. The connection tracking > offload > series will follow this one. > Hi Dave, As was agreed, i will apply this series and the two to follow to a side branch until all the connection tracking offloads patchsets are posted by Paul and reviewed/acked. in case of no objection i will apply this patchset to allow Paul to move forward with the other two connection tracking patchsets. Thanks, Saeed.
From: Saeed Mahameed <saeedm@mellanox.com> Date: Wed, 19 Feb 2020 02:43:08 +0000 > On Sun, 2020-02-16 at 12:01 +0200, Paul Blakey wrote: >> Hi David/Jakub/Saeed, >> >> TC multi chain configuration can cause offloaded tc chains to miss in >> hardware after jumping to some chain. In such cases the software >> should >> continue from the chain that was missed in hardware, as the hardware >> may have >> manipulated the packet and updated some counters. >> > > [...] > >> Note that miss path handling of multi-chain rules is a required >> infrastructure >> for connection tracking hardware offload. The connection tracking >> offload >> series will follow this one. >> > > Hi Dave, > > As was agreed, i will apply this series and the two to follow to a side > branch until all the connection tracking offloads patchsets are posted > by Paul and reviewed/acked. > > in case of no objection i will apply this patchset to allow Paul to > move forward with the other two connection tracking patchsets. I have no objection to this series, can you setup a pull request with this series in it that I can pull from into net-next? Thanks.
On Wed, 2020-02-19 at 16:12 -0800, David Miller wrote: > From: Saeed Mahameed <saeedm@mellanox.com> > Date: Wed, 19 Feb 2020 02:43:08 +0000 > > > On Sun, 2020-02-16 at 12:01 +0200, Paul Blakey wrote: > >> Hi David/Jakub/Saeed, > >> > >> TC multi chain configuration can cause offloaded tc chains to miss > in > >> hardware after jumping to some chain. In such cases the software > >> should > >> continue from the chain that was missed in hardware, as the > hardware > >> may have > >> manipulated the packet and updated some counters. > >> > > > > [...] > > > >> Note that miss path handling of multi-chain rules is a required > >> infrastructure > >> for connection tracking hardware offload. The connection tracking > >> offload > >> series will follow this one. > >> > > > > Hi Dave, > > > > As was agreed, i will apply this series and the two to follow to a > side > > branch until all the connection tracking offloads patchsets are > posted > > by Paul and reviewed/acked. > > > > in case of no objection i will apply this patchset to allow Paul to > > move forward with the other two connection tracking patchsets. > > I have no objection to this series, can you setup a pull request with > this > series in it that I can pull from into net-next? > Great, Yes i will setup the pull request. Series applied to ct-offload branch: https://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git/log/?h=ct-offload I will send the pull request once all connection tracking offload patches are posted and reviewed in net-next. Thanks.
Hi David/Jakub/Saeed, TC multi chain configuration can cause offloaded tc chains to miss in hardware after jumping to some chain. In such cases the software should continue from the chain that was missed in hardware, as the hardware may have manipulated the packet and updated some counters. The first four patches enables tc classification to start from a specified chain by re-using the existing TC_SKB_EXT skb extension. The next six patches are the Mellanox driver implementation of the miss path. The driver loads the last processed chain from HW register (reg_c0, then flow_tag) and stores it on the TC_SKB_EXT skb extension for continued processing in software. The final six patches introduce the Mellanox driver implementation for handling tunnel restore when the packet was decapsulated on first chain hop. Early decapsulation creates two issues: 1. The outer headers will not be available in later chains 2. If the HW will miss on later chains, the packet will come up to software without the tunnel header. Therefore, sw matches on the tunnel info will miss. Address these issues by mapping a unique id per tunnel info. The mapping is stored on hardware register (c1) when the packet is decapsulated. On miss, use the id to restore the tunnel info metadata on the skb. Note that miss path handling of multi-chain rules is a required infrastructure for connection tracking hardware offload. The connection tracking offload series will follow this one. Changelog: v2-v3: Split first patch to four Paul Blakey (16): net: sched: Introduce ingress classification function net: sched: Pass ingress block to tcf_classify_ingress net: sched: Change the block's chain list to an rcu list net: sched: Support specifying a starting chain via tc skb ext net/mlx5: Introduce mapping infra for mapping unique ids to data net/mlx5: E-Switch, Move source port on reg_c0 to the upper 16 bits net/mlx5: E-Switch, Get reg_c0 value on CQE net/mlx5: E-Switch, Mark miss packets with new chain id mapping net/mlx5e: Rx, Split rep rx mpwqe handler from nic net/mlx5: E-Switch, Restore chain id on miss net/mlx5e: Allow re-allocating mod header actions net/mlx5e: Move tc tunnel parsing logic with the rest at tc_tun module net/mlx5e: Disallow inserting vxlan/vlan egress rules without decap/pop net/mlx5e: Support inner header rewrite with goto action net/mlx5: E-Switch, Get reg_c1 value on miss net/mlx5e: Restore tunnel metadata on miss drivers/infiniband/hw/mlx5/main.c | 3 +- drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +- .../net/ethernet/mellanox/mlx5/core/en/mapping.c | 218 ++++++ .../net/ethernet/mellanox/mlx5/core/en/mapping.h | 27 + .../net/ethernet/mellanox/mlx5/core/en/tc_tun.c | 112 ++- .../net/ethernet/mellanox/mlx5/core/en/tc_tun.h | 3 +- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 4 +- drivers/net/ethernet/mellanox/mlx5/core/en_rep.h | 7 + drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 66 ++ drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 818 ++++++++++++++++----- drivers/net/ethernet/mellanox/mlx5/core/en_tc.h | 45 ++ drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 15 + .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 240 +++++- .../mellanox/mlx5/core/eswitch_offloads_chains.c | 130 +++- .../mellanox/mlx5/core/eswitch_offloads_chains.h | 4 +- drivers/net/ethernet/mellanox/mlx5/core/fs_core.c | 4 +- include/linux/mlx5/eswitch.h | 31 +- include/net/pkt_cls.h | 13 + include/net/sch_generic.h | 3 + net/core/dev.c | 3 +- net/sched/cls_api.c | 98 ++- net/sched/sch_generic.c | 8 + net/sched/sch_ingress.c | 11 +- 23 files changed, 1619 insertions(+), 246 deletions(-) create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/mapping.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/mapping.h