| Message ID | 1579623382-6934-1-git-send-email-paulb@mellanox.com |
|---|---|
| Headers | show |
| Series | Handle multi chain hardware misses | expand |
On Tue, 2020-01-21 at 18:16 +0200, Paul Blakey wrote: > 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 and Jakub, As Paul explained this is part one of two parts series, Assuming the review will go with no issues i would like to suggest the following acceptance options: option 1) I can create a separate side branch for connection tracking offload and once Paul submits the final patch of this feature and the mailing list review is complete, i can send to you full pull request with everything included .. option 2) you to apply directly to net-next both patchsets individually. (the normal process) Please let me know what works better for you. Personally I prefer option 1) so we won't endup stuck with only one half of the connection tracking series if the review of the 2nd part doesn't go as planned. Thanks, Saeed
From: Saeed Mahameed <saeedm@mellanox.com> Date: Tue, 21 Jan 2020 21:18:21 +0000 > On Tue, 2020-01-21 at 18:16 +0200, Paul Blakey wrote: >> 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 and Jakub, > > As Paul explained this is part one of two parts series, > > Assuming the review will go with no issues i would like to suggest the > following acceptance options: > > option 1) I can create a separate side branch for connection tracking > offload and once Paul submits the final patch of this feature and the > mailing list review is complete, i can send to you full pull request > with everything included .. > > option 2) you to apply directly to net-next both patchsets > individually. (the normal process) > > Please let me know what works better for you. > > Personally I prefer option 1) so we won't endup stuck with only one > half of the connection tracking series if the review of the 2nd part > doesn't go as planned. I'm fine with option #1 and will wait for that to appear in one of your future pull requests. It looks like patch #1 got some feedback and needs some modifications first though.
On Thu, 2020-01-23 at 10:54 +0100, David Miller wrote: > From: Saeed Mahameed <saeedm@mellanox.com> > Date: Tue, 21 Jan 2020 21:18:21 +0000 > > > On Tue, 2020-01-21 at 18:16 +0200, Paul Blakey wrote: > >> 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 and Jakub, > > > > As Paul explained this is part one of two parts series, > > > > Assuming the review will go with no issues i would like to suggest > the > > following acceptance options: > > > > option 1) I can create a separate side branch for connection > tracking > > offload and once Paul submits the final patch of this feature and > the > > mailing list review is complete, i can send to you full pull > request > > with everything included .. > > > > option 2) you to apply directly to net-next both patchsets > > individually. (the normal process) > > > > Please let me know what works better for you. > > > > Personally I prefer option 1) so we won't endup stuck with only one > > half of the connection tracking series if the review of the 2nd > part > > doesn't go as planned. > > I'm fine with option #1 and will wait for that to appear in one of Cool, will do option #1 then.. > your future pull requests. It looks like patch #1 got some feedback > and needs some modifications first though. > Yes, Paul will send V3 and I will wait for all the needed ACKs and Reviews, for this patchset and the ones to follow. Thanks, Saeed.
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 patch 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. Paul Blakey (12): net/mlx5: Add new driver lib for mappings 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 Vlad Buslov (1): net: sched: support skb chain ext in tc classification path drivers/infiniband/hw/mlx5/main.c | 3 +- drivers/net/ethernet/mellanox/mlx5/core/Makefile | 2 +- .../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 | 817 ++++++++++++++++----- drivers/net/ethernet/mellanox/mlx5/core/en_tc.h | 45 ++ drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 16 + .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 253 ++++++- .../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 +- .../net/ethernet/mellanox/mlx5/core/lib/mapping.c | 362 +++++++++ .../net/ethernet/mellanox/mlx5/core/lib/mapping.h | 31 + include/linux/mlx5/eswitch.h | 11 +- include/net/pkt_cls.h | 17 +- include/net/sch_generic.h | 6 +- net/core/dev.c | 6 +- net/sched/cls_api.c | 64 +- net/sched/sch_atm.c | 2 +- net/sched/sch_cake.c | 2 +- net/sched/sch_cbq.c | 2 +- net/sched/sch_drr.c | 2 +- net/sched/sch_dsmark.c | 2 +- net/sched/sch_fq_codel.c | 2 +- net/sched/sch_generic.c | 3 +- net/sched/sch_hfsc.c | 3 +- net/sched/sch_htb.c | 3 +- net/sched/sch_ingress.c | 5 +- net/sched/sch_multiq.c | 2 +- net/sched/sch_prio.c | 2 +- net/sched/sch_qfq.c | 2 +- net/sched/sch_sfb.c | 2 +- net/sched/sch_sfq.c | 2 +- 36 files changed, 1742 insertions(+), 257 deletions(-) create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/mapping.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/mapping.h