-----Original Message-----
From: Thomas Monjalon <redacted>
Sent: Friday 8 January 2021 10:24
To: Guo, Jia <redacted>; Zhang, Qi Z <redacted>;
Yigit, Ferruh [off-list ref]
Cc: Wu, Jingjing <redacted>; Yang, Qiming
[off-list ref]; Wang, Haiyue [off-list ref];
dev@dpdk.org; andrew.rybchenko@oktetlabs.ru; orika@nvidia.com;
getelson@nvidia.com; Dodji Seketeli [off-list ref]; Kinsella, Ray
[off-list ref]
Subject: Re: [dpdk-dev] [dpdk-dev v2 1/2] ethdev: add new tunnel type
for ecpri

08/01/2021 10:22, Ferruh Yigit:

quoted

On 1/7/2021 1:33 PM, Thomas Monjalon wrote:

quoted

07/01/2021 13:47, Zhang, Qi Z:

quoted

From: Thomas Monjalon <redacted>

quoted

07/01/2021 10:32, Guo, Jia:

quoted

From: Thomas Monjalon <redacted>

quoted

Sorry, it is a nack.
BTW, it is probably breaking the ABI because of

RTE_TUNNEL_TYPE_MAX.

quoted

quoted

quoted

Yes that may break the ABI but fortunately the checking-abi-

compatibility tool shows negative :) , thanks Ferruh' s guide.

quoted

quoted

quoted

https://github.com/ferruhy/dpdk/actions/runs/468859673

That's very strange. An enum value is changed.
Why it is not flagged by libabigail?

As long as the enum values not sent to the application and kept

within

quoted

the library, changing their values shouldn't be problem.

But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h so it
is exposed to the application.
I think it is a case of ABI breakage.

Really a lot depends on context, Thomas is right it is hard to predict how these _MAX values are used.

We have seen cases in the past where _MAX enumeration values have been used to size arrays the like - I don't immediately see that issue here. My understanding is that the only consumer of this enumeration is rte_eth_dev_udp_tunnel_port_add and rte_eth_dev_udp_tunnel_port_delete, right? On face value, impact looks negligible. 

I will take a look at why libabigail doesn't complain.