[dpdk-stable] [dpdk-dev] [PATCH v3] net/mlx5: fix tunnel offload private items location

Ferruh Yigit ferruh.yigit at intel.com
Wed May 5 19:45:27 CEST 2021


On 5/4/2021 10:12 AM, Gregory Etelson wrote:
> Hello Ferruh,
> 
> [:snip:]
> 
>> Hi Gregory,
>>
>> The were some questions around testpmd part of this patch in previous
>> version, they are not answered and this version is dropping the testpmd
>> part.
>>
> 
> The tunnel offload API allows application to place tunnel offload elements at any valid location in a flow rule. 

How PMD should detect the tunnel offload elements?

And which API are we talking about, is there enough documentation in the API
about the location of the tunnel offload elements, or should we clarify it more?

> Current testpmd code places tunnel offload items
> at the beginning of pattern array and tunnel offload actions at the beginning of actions array.

Got it, so this patch is removing false expectation (about the location of the
tunnel offload elements in flow rule) in the PMD, right?

As far as I understand testpmd already satisfies this false expectation, so the
problem should not be visible with testpmd.
Was there a visible user impact, like any application failing because of this
false expectation, or is this theoretical fix to be correct with API contract?


btw, I can see 'MLX5_RTE_FLOW_ITEM_TYPE_TUNNEL' still checked if it in the first
location of the items (items[0].type), in 'flow_dv_validate()', 'mlx5_flow_dv.c'
https://git.dpdk.org/dpdk/tree/drivers/net/mlx5/mlx5_flow_dv.c?h=v21.05-rc1#n6298
Can you please confirm that this is expected?

> The testpmd patch in v1 & v2 changed location of tunnel offload elements in a flow rule.
> 
>> Is it safe to remove the testpmd part? If so why was the changes for at first
>> place?
>>
> 
> That patch was not a fix - it emphasized general usage of the tunnel offload API.
> Current testpmd code works fine.
> 
>> And can you please reply to the questions on the testpmd patch for the
>> record?
>>
> 
> I'll add my replies.
> 
>> Thanks,
>> Ferruh
> 
> Regards,
> Gregory
> 



More information about the stable mailing list