[ovs-dev] [PATCH V2 10/14] netdev-offload-dpdk: Support tunnel pop action

Eli Britstein elibr at nvidia.com
Mon Mar 1 11:50:00 UTC 2021


On 3/1/2021 1:30 PM, Sriharsha Basavapatna wrote:
>>>> The details of this array is under the PMD's responsibility.
>>> So this means the PMD has to pick a range of private action values
>>> that are not defined in rte_flow.h,  but what if later a new action
>>> type with the same value is added to rte_flow.h ?
>>> The other question is if the PMD could use one of the existing action
>>> types in rte_flow.h [i.e, to avoid defining its own private action
>>> types] and return it in the opaque action array ?
>> The goal of the API is to be able for each PMD to have its own
>> implementation, private actions or not.
>>
>> For the application, this is opaque, as it doesn't know the details of it.
>>
>> If there is a change in rte_flow.h, it means ABI change in DPDK. DPDK
>> release policy protects us in a sense.
> Take this example: assume action type 100 is not yet defined in
> rte_flow.h and a PMD uses this value for a new private action that it
> defines. Later, if a new standard action type is added to rte_flow.h
> with the same value, then the PMD has no way to distinguish if the
> action is a standard action or its private action. Also, this private
> action type defined by some vendor's PMD could be 100 and it could be
> 200 in another vendor's PMD. So don't we need to ensure that the
> standard action types and private action types don't overlap ? One way
> to handle this might be to reserve a range of values in rte_flow.h as
> a vendor specific range, for example 100 to 200. And each PMD could
> define its own private action types within this range, since it is
> ensured that no standard action types would be defined in that range.

I don't know regarding other PMDs, but at least for mlx5, the "private" 
are negative values, or for unsigned > 2^31, so I don't think they would 
be a conflict.

I suppose DPDK PMDs should follow changes in rte_flow.h. Anyway, it is 
not related to OVS.

>


More information about the dev mailing list