Hi Stephen,
If I understand correctly, do you mean that the internal value and rte_flow API
value may have some conflict?
All the MLX5 internal enum values start from INT_MIN. When treating it as a int
value, it would not have the same value with rte_flow enums, unless all the
2^^32 are defined.
But yes, this has some risk since there is no limitation of the values in the
rte_flow API.
BR. Bing
> -----Original Message-----
> From: Stephen Hemminger <step...@networkplumber.org>
> Sent: Friday, June 30, 2023 2:09 PM
> To: Bing Zhao <bi...@nvidia.com>
> Cc: Matan Azrad <ma...@nvidia.com>; Slava Ovsiienko
> <viachesl...@nvidia.com>; Ori Kam <or...@nvidia.com>; Suanming Mou
> <suanmi...@nvidia.com>; Raslan Darawsheh <rasl...@nvidia.com>;
> dev@dpdk.org; Michael Baum <michae...@nvidia.com>
> Subject: Re: [PATCH 1/7] net/mlx5: fix the modify field check of tag
>
> External email: Use caution opening links or attachments
>
>
> On Fri, 30 Jun 2023 08:43:03 +0300
> Bing Zhao <bi...@nvidia.com> wrote:
>
> > @@ -1117,9 +1117,10 @@ flow_dv_fetch_field(const uint8_t *data,
> > uint32_t size) static inline bool
> > flow_modify_field_support_tag_array(enum rte_flow_field_id field) {
> > - switch (field) {
> > + switch ((int)field) {
> > case RTE_FLOW_FIELD_TAG:
> > case RTE_FLOW_FIELD_MPLS:
> > + case MLX5_RTE_FLOW_FIELD_META_REG:
>
> Mixing internal and API fields seems like something that could get easily
> broken by changes to rte_flow.
