lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 24 Mar 2020 18:15:22 +0200
From:   Vlad Buslov <vladbu@...lanox.com>
To:     wenxu@...oud.cn
Cc:     saeedm@...lanox.com, paulb@...lanox.com, vladbu@...lanox.com,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next v6 2/2] net/mlx5e: add mlx5e_rep_indr_setup_ft_cb support


On Tue 24 Mar 2020 at 16:44, wenxu@...oud.cn wrote:
> From: wenxu <wenxu@...oud.cn>
>
> Add mlx5e_rep_indr_setup_ft_cb to support indr block setup
> in FT mode.
> Both tc rules and flow table rules are of the same format,
> It can re-use tc parsing for that, and move the flow table rules
> to their steering domain(the specific chain_index), the indr
> block offload in FT also follow this scenario.
>
> Signed-off-by: wenxu <wenxu@...oud.cn>
> ---
> v6: modify the comments
>
>  drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 52 ++++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> index 057f5f9..30c81c3 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rep.c
> @@ -732,6 +732,55 @@ static int mlx5e_rep_indr_setup_tc_cb(enum tc_setup_type type,
>  	}
>  }
>
> +static int mlx5e_rep_indr_setup_ft_cb(enum tc_setup_type type,
> +				      void *type_data, void *indr_priv)
> +{
> +	struct mlx5e_rep_indr_block_priv *priv = indr_priv;
> +	struct flow_cls_offload *f = type_data;
> +	struct flow_cls_offload tmp;
> +	struct mlx5e_priv *mpriv;
> +	struct mlx5_eswitch *esw;
> +	unsigned long flags;
> +	int err;
> +
> +	mpriv = netdev_priv(priv->rpriv->netdev);
> +	esw = mpriv->mdev->priv.eswitch;
> +
> +	flags = MLX5_TC_FLAG(EGRESS) |
> +		MLX5_TC_FLAG(ESW_OFFLOAD) |
> +		MLX5_TC_FLAG(FT_OFFLOAD);
> +
> +	switch (type) {
> +	case TC_SETUP_CLSFLOWER:
> +		memcpy(&tmp, f, sizeof(*f));
> +
> +		if (!mlx5_esw_chains_prios_supported(esw))
> +			return -EOPNOTSUPP;
> +
> +		/* Re-use tc offload path by moving the ft flow to the
> +		 * reserved ft chain.
> +		 *
> +		 * FT offload can use prio range [0, INT_MAX], so we normalize
> +		 * it to range [1, mlx5_esw_chains_get_prio_range(esw)]
> +		 * as with tc, where prio 0 isn't supported.
> +		 *
> +		 * We only support chain 0 of FT offload.
> +		 */
> +		if (tmp.common.prio >= mlx5_esw_chains_get_prio_range(esw))
> +			return -EOPNOTSUPP;
> +		if (tmp.common.chain_index != 0)
> +			return -EOPNOTSUPP;

Here you have three consecutive conditionals returning the same value
-EOPNOTSUPP. Perhaps it would be better to combine all the checks in
single if statement?

> +
> +		tmp.common.chain_index = mlx5_esw_chains_get_ft_chain(esw);
> +		tmp.common.prio++;
> +		err = mlx5e_rep_indr_offload(priv->netdev, &tmp, priv, flags);
> +		memcpy(&f->stats, &tmp.stats, sizeof(f->stats));
> +		return err;
> +	default:
> +		return -EOPNOTSUPP;
> +	}
> +}
> +
>  static void mlx5e_rep_indr_block_unbind(void *cb_priv)
>  {
>  	struct mlx5e_rep_indr_block_priv *indr_priv = cb_priv;
> @@ -809,6 +858,9 @@ int mlx5e_rep_indr_setup_cb(struct net_device *netdev, void *cb_priv,
>  	case TC_SETUP_BLOCK:
>  		return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
>  						  mlx5e_rep_indr_setup_tc_cb);
> +	case TC_SETUP_FT:
> +		return mlx5e_rep_indr_setup_block(netdev, cb_priv, type_data,
> +						  mlx5e_rep_indr_setup_ft_cb);
>  	default:
>  		return -EOPNOTSUPP;
>  	}

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ