From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2DB1CA0524 for ; Fri, 6 Nov 2020 12:20:08 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 21EFE5AB9; Fri, 6 Nov 2020 12:20:07 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 09AA65AB9; Fri, 6 Nov 2020 12:20:03 +0100 (CET) IronPort-SDR: axKM44XhcmzWYnybQmp16IcuTjUXW1K+U+8yD1kye2c0Qm+gQ7FexKZ/rGT/PnkNTcYWwd4/Tm KwMfIl4mBemw== X-IronPort-AV: E=McAfee;i="6000,8403,9796"; a="254239178" X-IronPort-AV: E=Sophos;i="5.77,456,1596524400"; d="scan'208";a="254239178" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2020 03:20:02 -0800 IronPort-SDR: x2vi18aMLbzplrQ7Oc2ZmBrNRh0AqI2GfTBzeya8hHosOJSjZ3icGERzYTf/HewubM1Lblrq0p 22yxqhIlHWzw== X-IronPort-AV: E=Sophos;i="5.77,456,1596524400"; d="scan'208";a="539805760" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.228.45]) ([10.213.228.45]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2020 03:20:00 -0800 To: Bing Zhao , viacheslavo@nvidia.com, matan@nvidia.com Cc: dev@dpdk.org, orika@nvidia.com, rasland@nvidia.com, stable@dpdk.org References: <1604382118-336293-1-git-send-email-bingz@nvidia.com> From: Ferruh Yigit Message-ID: Date: Fri, 6 Nov 2020 11:19:56 +0000 MIME-Version: 1.0 In-Reply-To: <1604382118-336293-1-git-send-email-bingz@nvidia.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH] net/mlx5: fix the eCPRI common header endianness X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" 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@dpdk.org > > Signed-off-by: Bing Zhao > Acked-by: Viacheslav Ovsiienko > --- > 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: >