1. 18 Nov, 2021 17 commits
  2. 17 Nov, 2021 19 commits
  3. 16 Nov, 2021 4 commits
    • Raed Salem's avatar
      net/mlx5: E-Switch, return error if encap isn't supported · c4c31767
      Raed Salem authored
      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: 8e0aa4bc ("net/mlx5: E-switch, Protect eswitch mode changes")
      Signed-off-by: default avatarRaed Salem <raeds@nvidia.com>
      Reviewed-by: default avatarMark Bloch <mbloch@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      c4c31767
    • Maher Sanalla's avatar
      net/mlx5: Lag, update tracker when state change event received · ae396d85
      Maher Sanalla authored
      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: 9b412cc3 ("net/mlx5e: Add LAG warning if bond slave is not lag master")
      Signed-off-by: default avatarMaher Sanalla <msanalla@nvidia.com>
      Reviewed-by: default avatarMark Bloch <mbloch@nvidia.com>
      Reviewed-by: default avatarJianbo Liu <jianbol@nvidia.com>
      Reviewed-by: default avatarRoi Dayan <roid@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      ae396d85
    • Roi Dayan's avatar
      net/mlx5e: CT, Fix multiple allocations and memleak of mod acts · 806401c2
      Roi Dayan authored
      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: 1ef3018f ("net/mlx5e: CT: Support clear action")
      Signed-off-by: default avatarRoi Dayan <roid@nvidia.com>
      Reviewed-by: default avatarPaul Blakey <paulb@nvidia.com>
      Reviewed-by: default avatarMaor Dickman <maord@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      806401c2
    • Avihai Horon's avatar
      net/mlx5: Fix flow counters SF bulk query len · 38a54cae
      Avihai Horon authored
      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: 2fdeb4f4 ("net/mlx5: Reduce flow counters bulk query buffer size for SFs")
      Signed-off-by: default avatarAvihai Horon <avihaih@nvidia.com>
      Signed-off-by: default avatarSaeed Mahameed <saeedm@nvidia.com>
      38a54cae