[dpdk-dev] [PATCH] net/mlx5: fix the eCPRI common header endianness

[Ferruh Yigit]

On 11/3/2020 5:41 AM, Bing Zhao wrote:
> The input header of a RTE flow item is with network byte order. In
> the host with little endian, the bit field order are the same as the
> byte order.
> When checking the an eCPRI message type, the wrong field will be
> selected. Right now, since the whole u32 is being checked and for
> all types, the following implementation is unique. There is no
> functional risk but it is still an error to fix.
 >

Isn't the 'ecpri_v' filled by application (CPU), why there is an assumption that 
it is big endian?

And even if it is big endian, it should be broken previously right? Since it was 
checking wrong field as 'type' as you said, why there were no functional risk?

> 
> Fixes: daa38a8924a0 ("net/mlx5: add flow translation of eCPRI header")
> 
> Cc: stable at dpdk.org
> 
> Signed-off-by: Bing Zhao <bingz at nvidia.com>
> Acked-by: Viacheslav Ovsiienko <viacheslavo at nvidia.com>
> ---
>   drivers/net/mlx5/mlx5_flow_dv.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
> index 01b6e7c..7af01e9 100644
> --- a/drivers/net/mlx5/mlx5_flow_dv.c
> +++ b/drivers/net/mlx5/mlx5_flow_dv.c
> @@ -7798,6 +7798,7 @@ struct mlx5_hlist_entry *
>   	struct mlx5_priv *priv = dev->data->dev_private;
>   	const struct rte_flow_item_ecpri *ecpri_m = item->mask;
>   	const struct rte_flow_item_ecpri *ecpri_v = item->spec;
> +	struct rte_ecpri_common_hdr common;
>   	void *misc4_m = MLX5_ADDR_OF(fte_match_param, matcher,
>   				     misc_parameters_4);
>   	void *misc4_v = MLX5_ADDR_OF(fte_match_param, key, misc_parameters_4);
> @@ -7838,7 +7839,8 @@ struct mlx5_hlist_entry *
>   	 * Some wildcard rules only matching type field should be supported.
>   	 */
>   	if (ecpri_m->hdr.dummy[0]) {
> -		switch (ecpri_v->hdr.common.type) {
> +		common.u32 = rte_be_to_cpu_32(ecpri_v->hdr.common.u32);
> +		switch (common.type) {
>   		case RTE_ECPRI_MSG_TYPE_IQ_DATA:
>   		case RTE_ECPRI_MSG_TYPE_RTC_CTRL:
>   		case RTE_ECPRI_MSG_TYPE_DLY_MSR:
>