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.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
