08/01/2021 15:07, Kinsella, Ray:

From: Thomas Monjalon <redacted>

quoted

08/01/2021 11:43, Ferruh Yigit:

quoted

On 1/8/2021 10:23 AM, Thomas Monjalon wrote:

quoted

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

quoted

quoted

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

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

quoted

quoted

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 the library, changing their values shouldn't be problem.

But RTE_TUNNEL_TYPE_MAX is part of lib/librte_ethdev/rte_ethdev.h

so

quoted

quoted

it is exposed to the application.
I think it is a case of ABI breakage.

Yes it is exposed to the application. But in runtime does it

exchanged

quoted

between library and application is the issue I think.
For this case it seems it is not, so not an ABI break.

If I create a table of size RTE_TUNNEL_TYPE_MAX with DPDK 20.11, I will
get an overflow when writing to the new ECPRI index.

I guess the question is - are you likely to do this?

As said below, no I cannot think about such a case myself.

quoted

The question is: can I receive the ECPRI value dynamically from ethdev?
If yes, it is an ABI breakage. But I cannot think of such case now.