On 2/21/20 1:25 PM, Ferruh Yigit wrote: > On 1/30/2020 2:20 PM, Ferruh Yigit wrote: >> Adding the deprecation notice as reminder for next ABI breakage release >> (20.11). >> This one time breakage is required to be able to extend enum/define >> without breaking ABI. >> >> Signed-off-by: Ferruh Yigit <ferruh.yi...@intel.com> >> --- >> doc/guides/rel_notes/deprecation.rst | 14 ++++++++++++++ >> 1 file changed, 14 insertions(+) >> >> diff --git a/doc/guides/rel_notes/deprecation.rst >> b/doc/guides/rel_notes/deprecation.rst >> index dfcca87ab..99d81564a 100644 >> --- a/doc/guides/rel_notes/deprecation.rst >> +++ b/doc/guides/rel_notes/deprecation.rst >> @@ -38,6 +38,20 @@ Deprecation Notices >> remove it from the externally visible ABI and allow it to be updated in >> the >> future. >> >> +* lib: will fix extending some enum/define breaking the ABI. There are >> multiple >> + samples in DPDK that enum/define terminated with a ``.*MAX.*`` value >> which is >> + used by iterators, and arrays holding these values are sized with this >> + ``.*MAX.*`` value. So extending this enum/define increases the ``.*MAX.*`` >> + value which increases the size of the array and depending on how/where the >> + array is used this may break the ABI. >> + ``RTE_ETH_FLOW_MAX`` is one sample of the mentioned case, adding a new >> flow >> + type will break the ABI because of ``flex_mask[RTE_ETH_FLOW_MAX]`` array >> + usage in following public struct hierarchy: >> + ``rte_eth_fdir_flex_conf -> rte_fdir_conf -> rte_eth_conf (in the >> middle)``. >> + Need to identify this kind of usages and fix in 20.11, otherwise this >> blocks >> + us extending existing enum/define. >> + One solution can be using a fixed size array instead of ``.*MAX.*`` value. >> + >> * dpaa2: removal of ``rte_dpaa2_memsegs`` structure which has been replaced >> by a pa-va search library. This structure was earlier being used for >> holding >> memory segments used by dpaa2 driver for faster pa->va translation. This >> > Reminder of this deprecation notice.
Acked-by: Andrew Rybchenko <arybche...@oktetlabs.ru>
