[dpdk-stable] [PATCH] net/mlx5: fix parsing all-multicast from flow item
Yongseok Koh
yskoh at mellanox.com
Fri Jan 12 23:36:44 CET 2018
> On Jan 11, 2018, at 12:20 AM, Nélio Laranjeiro <nelio.laranjeiro at 6wind.com> wrote:
>
> On Wed, Jan 10, 2018 at 11:51:53PM -0800, Yongseok Koh wrote:
>> As the dst_mac of allmulti is already masked with the mask, it has 0x01 in
>> the first octet. Checking the least significant bit only can't distinguish
>> it from broadcast or IPv6 multicast.
>>
>> Fixes: bb47fb6e6067 ("net/mlx5: fix flow type for allmulti rules")
>> Cc: stable at dpdk.org
>>
>> Signed-off-by: Yongseok Koh <yskoh at mellanox.com>
>> ---
>> drivers/net/mlx5/mlx5_flow.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
>> index 305b2ec01..d01c8069b 100644
>> --- a/drivers/net/mlx5/mlx5_flow.c
>> +++ b/drivers/net/mlx5/mlx5_flow.c
>> @@ -1281,7 +1281,7 @@ mlx5_flow_create_eth(const struct rte_flow_item *item,
>> eth.val.ether_type &= eth.mask.ether_type;
>> }
>> mlx5_flow_create_copy(parser, ð, eth_size);
>> - parser->allmulti = eth.val.dst_mac[0] & 1;
>> + parser->allmulti = eth.val.dst_mac[0] == 0x01;
>> return 0;
>> }
>>
>> --
>> 2.11.0
>>
>
> Seems you are introducing a bug, for broadcast Mac addresses, this will
> not work i.e. 0xff != 0x01 but it as the multicast bit set. From my
> understanding, Verbs flow attribute must also be modified in such
> situation.
>
> Are you sure about this change?
Indeed. I was trying to fix a bug about the control flow. In
priv_dev_traffic_enable(), if VLAN filter is configured, it isn't properly set
for broadcast. Looks like code should be changed a lot regarding allmulti. And I
heard Raslan is preparing it. I'm taking back this patch so that Raslan include
the fix in his patch set.
Thanks,
Yongseok
More information about the stable
mailing list