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: sta...@dpdk.org
Signed-off-by: Bing Zhao <bi...@nvidia.com>
Acked-by: Viacheslav Ovsiienko <viachesl...@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:
