From: Tariq Toukan <tariqt@nvidia.com>
For the TLS RX resync flow, we maintain a list of TLS contexts
that require some attention, to communicate their resync information
to the HW.
Here we fix list corruptions, by protecting the entries against
movements coming from resync_handle_seq_match(), until their resync
handling in napi is fully completed.
Fixes: e9ce991bce5b ("net/mlx5e: kTLS, Add resiliency to RX resync failures")
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Maxim Mikityanskiy <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
.../mellanox/mlx5/core/en_accel/ktls_rx.c | 23 ++++++++++++++-----
1 file changed, 17 insertions(+), 6 deletions(-)
From: Vlad Buslov <redacted>
Function mlx5e_take_tmp_flow() skips flows with zero reference count. This
can cause syndrome 0x179e84 when the called from neigh or route update code
and the skipped flow is not removed from the hardware by the time
underlying encap/decap resource is deleted. Add new completion
'del_hw_done' that is completed when flow is unoffloaded. This is safe to
do because flow with reference count zero needs to be detached from
encap/decap entry before its memory is deallocated, which requires taking
the encap_tbl_lock mutex that is held by the event handlers code.
Fixes: 8914add2c9e5 ("net/mlx5e: Handle FIB events to update tunnel endpoint device")
Signed-off-by: Vlad Buslov <redacted>
Reviewed-by: Roi Dayan <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_encap.c | 8 +++++++-
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 2 ++
3 files changed, 10 insertions(+), 1 deletion(-)
@@ -102,6 +102,7 @@ struct mlx5e_tc_flow {refcount_trefcnt;structrcu_headrcu_head;structcompletioninit_done;+structcompletiondel_hw_done;inttunnel_id;/* the mapped tunnel id of this flow */structmlx5_flow_attr*attr;};
@@ -245,8 +245,14 @@ static void mlx5e_take_tmp_flow(struct mlx5e_tc_flow *flow,structlist_head*flow_list,intindex){-if(IS_ERR(mlx5e_flow_get(flow)))+if(IS_ERR(mlx5e_flow_get(flow))){+/* Flow is being deleted concurrently. Wait for it to be+*unoffloadedfromhardware,otherwisedeletingencapwill+*fail.+*/+wait_for_completion(&flow->del_hw_done);return;+}wait_for_completion(&flow->init_done);flow->tmp_entry_index=index;
From: Paul Blakey <redacted>
E-Switch encap mode is relevant only when in switchdev mode.
The RDMA driver can query the encap configuration via
mlx5_eswitch_get_encap_mode(). Make sure it returns the currently
used mode and not the set one.
This reverts the cited commit which reset the encap mode
on entering switchdev and fixes the original issue properly.
Fixes: 9a64144d683a ("net/mlx5: E-Switch, Fix default encap mode")
Signed-off-by: Paul Blakey <redacted>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Maor Dickman <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 9 +++++++--
.../net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 7 -------
include/linux/mlx5/eswitch.h | 4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
From: Yevgeny Kliteynik <redacted>
When querying eswitch manager vport capabilities as "other = 1",
we encounter a FW compatibility issue with older FW versions.
To maintain backward compatibility, eswitch manager vport should
be queried as "other = 0" vport both for ECPF and non-ECPF cases.
This patch fixes these queries and improves the code readability
by handling eswitch manager and uplink vports separately, avoiding
the excessive 'if' conditions. Also, uplink caps are stored similar
to esw manager and not as part of xarray.
Fixes: dd4acb2a0954 ("net/mlx5: DR, Add missing query for vport 0")
Signed-off-by: Yevgeny Kliteynik <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
.../mellanox/mlx5/core/steering/dr_domain.c | 56 ++++++++-----------
.../mellanox/mlx5/core/steering/dr_types.h | 1 +
2 files changed, 24 insertions(+), 33 deletions(-)
From: Mark Bloch <mbloch@nvidia.com>
A user can enable VFs without changing E-Switch mode, this can happen
when a user moves straight to switchdev mode and only once in switchdev
VFs are enabled via the sysfs interface.
The cited commit assumed this isn't possible and exposed a single
API function where the E-switch calls into the lag code, breaks the lag
and prevents any other lag operations to take place until the
E-switch update has ended.
Breaking the hardware lag when it isn't needed can make it such that
hardware lag can't be enabled again.
In the sysfs call path check if the current E-Switch mode is NONE,
in the context of the function it can only mean the E-Switch is moving
out of NONE mode and the hardware lag should be disabled and enabled
once the mode change has ended. If the mode isn't NONE it means
VFs are about to be enabled and such operation doesn't require
toggling the hardware lag.
Fixes: cac1eb2cf2e3 ("net/mlx5: Lag, properly lock eswitch if needed")
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
@@ -1305,12 +1305,17 @@ int mlx5_eswitch_enable_locked(struct mlx5_eswitch *esw, int mode, int num_vfs)*/intmlx5_eswitch_enable(structmlx5_eswitch*esw,intnum_vfs){+booltoggle_lag;intret;if(!mlx5_esw_allowed(esw))return0;-mlx5_lag_disable_change(esw->dev);+toggle_lag=esw->mode==MLX5_ESWITCH_NONE;++if(toggle_lag)+mlx5_lag_disable_change(esw->dev);+down_write(&esw->mode_lock);if(esw->mode==MLX5_ESWITCH_NONE){ret=mlx5_eswitch_enable_locked(esw,MLX5_ESWITCH_LEGACY,num_vfs);
@@ -1324,7 +1329,10 @@ int mlx5_eswitch_enable(struct mlx5_eswitch *esw, int num_vfs)esw->esw_funcs.num_vfs=num_vfs;}up_write(&esw->mode_lock);-mlx5_lag_enable_change(esw->dev);++if(toggle_lag)+mlx5_lag_enable_change(esw->dev);+returnret;}
From: Raed Salem <redacted>
On regular ConnectX HCAs getting encap mode isn't supported when the
E-Switch is in NONE mode. Current code would return no error code when
trying to get encap mode in such case which is wrong.
Fix by returning error value to indicate failure to caller in such case.
Fixes: 8e0aa4bc959c ("net/mlx5: E-switch, Protect eswitch mode changes")
Signed-off-by: Raed Salem <redacted>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Maor Dickman <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Avihai Horon <redacted>
When doing a flow counters bulk query, the number of counters to query
must be aligned to 4. Current SF bulk query len is not aligned to 4,
which leads to an error when trying to query more than 4 counters.
Fix it by aligning SF bulk query len to 4.
Fixes: 2fdeb4f4c2ae ("net/mlx5: Reduce flow counters bulk query buffer size for SFs")
Signed-off-by: Avihai Horon <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/fs_counters.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -40,7 +40,7 @@#define MLX5_FC_STATS_PERIOD msecs_to_jiffies(1000)/* Max number of counters to query in bulk read is 32K */#define MLX5_SW_MAX_COUNTERS_BULK BIT(15)-#define MLX5_SF_NUM_COUNTERS_BULK 6+#define MLX5_SF_NUM_COUNTERS_BULK 8#define MLX5_FC_POOL_MAX_THRESHOLD BIT(18)#define MLX5_FC_POOL_USED_BUFF_RATIO 10
From: Roi Dayan <redacted>
CT clear action offload adds additional mod hdr actions to the
flow's original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.
Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.
Also the driver never releases the allocated mod hdr actions and
causing a memleak.
Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().
backtrace:
[<000000007316e2f3>] krealloc+0x83/0xd0
[<00000000ef157de1>] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
[<00000000970ce4ae>] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
[<0000000067c5fa17>] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
[<00000000d032eb98>] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
[<00000000fd23b869>] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
[<000000004fc24acc>] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
[<00000000dc741c17>] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
[<00000000e92e49d7>] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
[<00000000f60f5602>] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]
Fixes: 1ef3018f5af3 ("net/mlx5e: CT: Support clear action")
Signed-off-by: Roi Dayan <redacted>
Reviewed-by: Paul Blakey <redacted>
Reviewed-by: Maor Dickman <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
.../ethernet/mellanox/mlx5/core/en/tc_ct.c | 26 ++++++++++++-------
.../ethernet/mellanox/mlx5/core/en/tc_ct.h | 2 ++
.../net/ethernet/mellanox/mlx5/core/en_tc.c | 8 ++++--
3 files changed, 25 insertions(+), 11 deletions(-)
@@ -1369,6 +1373,17 @@ mlx5_tc_ct_parse_action(struct mlx5_tc_ct_priv *priv,attr->ct_attr.ct_action=act->ct.action;attr->ct_attr.nf_ft=act->ct.flow_table;+if(!clear_action)+gotoout;++err=mlx5_tc_ct_entry_set_registers(priv,mod_acts,0,0,0,0);+if(err){+NL_SET_ERR_MSG_MOD(extack,"Failed to set registers for ct clear");+returnerr;+}+attr->action|=MLX5_FLOW_CONTEXT_ACTION_MOD_HDR;++out:return0;}
@@ -1898,23 +1913,16 @@ __mlx5_tc_ct_flow_offload_clear(struct mlx5_tc_ct_priv *ct_priv,memcpy(pre_ct_attr,attr,attr_sz);-err=mlx5_tc_ct_entry_set_registers(ct_priv,mod_acts,0,0,0,0);-if(err){-ct_dbg("Failed to set register for ct clear");-gotoerr_set_registers;-}-mod_hdr=mlx5_modify_header_alloc(priv->mdev,ct_priv->ns_type,mod_acts->num_actions,mod_acts->actions);if(IS_ERR(mod_hdr)){err=PTR_ERR(mod_hdr);ct_dbg("Failed to add create ct clear mod hdr");-gotoerr_set_registers;+gotoerr_mod_hdr;}pre_ct_attr->modify_hdr=mod_hdr;-pre_ct_attr->action|=MLX5_FLOW_CONTEXT_ACTION_MOD_HDR;rule=mlx5_tc_rule_insert(priv,orig_spec,pre_ct_attr);if(IS_ERR(rule)){
@@ -4277,7 +4279,9 @@ static int parse_tc_fdb_actions(struct mlx5e_priv *priv,NL_SET_ERR_MSG_MOD(extack,"Sample action with connection tracking is not supported");return-EOPNOTSUPP;}-err=mlx5_tc_ct_parse_action(get_ct_priv(priv),attr,act,extack);+err=mlx5_tc_ct_parse_action(get_ct_priv(priv),attr,+&parse_attr->mod_hdr_acts,+act,extack);if(err)returnerr;
From: Maher Sanalla <redacted>
Currently, In NETDEV_CHANGELOWERSTATE/NETDEV_CHANGEUPPERSTATE events
handling, tracking is not fully completed if the LAG device is not ready
at the time the events occur. But, we must keep track of the upper and
lower states after receiving the events because RoCE needs this info in
mlx5_lag_get_roce_netdev() - in order to return the corresponding port
that its running on. Returning the wrong (not most recent) port will lead
to gids table being incorrect.
For example: If during the attachment of a slave to the bond, the other
non-attached port performs pci_reload, then the LAG device is not ready,
but that should not result in dismissing attached slave tracker update
automatically (which is performed in mlx5_handle_changelowerstate()), Since
these events might not come later, which can lead to both bond ports
having tx_enabled=0 - which is not a valid state of LAG bond.
Fixes: 9b412cc35f00 ("net/mlx5e: Add LAG warning if bond slave is not lag master")
Signed-off-by: Maher Sanalla <redacted>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Reviewed-by: Jianbo Liu <redacted>
Reviewed-by: Roi Dayan <redacted>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
.../net/ethernet/mellanox/mlx5/core/lag/lag.c | 28 +++++++++----------
1 file changed, 13 insertions(+), 15 deletions(-)
@@ -615,6 +615,7 @@ static int mlx5_handle_changeupper_event(struct mlx5_lag *ldev,boolis_bonded,is_in_lag,mode_supported;intbond_status=0;intnum_slaves=0;+intchanged=0;intidx;if(!netif_is_lag_master(upper))
@@ -653,27 +654,27 @@ static int mlx5_handle_changeupper_event(struct mlx5_lag *ldev,*/is_in_lag=num_slaves==MLX5_MAX_PORTS&&bond_status==0x3;-if(!mlx5_lag_is_ready(ldev)&&is_in_lag){-NL_SET_ERR_MSG_MOD(info->info.extack,-"Can't activate LAG offload, PF is configured with more than 64 VFs");-return0;-}-/* Lag mode must be activebackup or hash. */mode_supported=tracker->tx_type==NETDEV_LAG_TX_TYPE_ACTIVEBACKUP||tracker->tx_type==NETDEV_LAG_TX_TYPE_HASH;-if(is_in_lag&&!mode_supported)-NL_SET_ERR_MSG_MOD(info->info.extack,-"Can't activate LAG offload, TX type isn't supported");-is_bonded=is_in_lag&&mode_supported;if(tracker->is_bonded!=is_bonded){tracker->is_bonded=is_bonded;-return1;+changed=1;}-return0;+if(!is_in_lag)+returnchanged;++if(!mlx5_lag_is_ready(ldev))+NL_SET_ERR_MSG_MOD(info->info.extack,+"Can't activate LAG offload, PF is configured with more than 64 VFs");+elseif(!mode_supported)+NL_SET_ERR_MSG_MOD(info->info.extack,+"Can't activate LAG offload, TX type isn't supported");++returnchanged;}staticintmlx5_handle_changelowerstate_event(structmlx5_lag*ldev,
@@ -716,9 +717,6 @@ static int mlx5_lag_netdev_event(struct notifier_block *this,ldev=container_of(this,structmlx5_lag,nb);-if(!mlx5_lag_is_ready(ldev)&&event==NETDEV_CHANGELOWERSTATE)-returnNOTIFY_DONE;-tracker=ldev->tracker;switch(event){
Hello:
This series was applied to netdev/net.git (master)
by Saeed Mahameed [off-list ref]:
On Tue, 16 Nov 2021 12:23:10 -0800 you wrote:
From: Tariq Toukan <tariqt@nvidia.com>
For the TLS RX resync flow, we maintain a list of TLS contexts
that require some attention, to communicate their resync information
to the HW.
Here we fix list corruptions, by protecting the entries against
movements coming from resync_handle_seq_match(), until their resync
handling in napi is fully completed.
[...]