07/07/2021 11:36, David Marchand: > On Wed, Jul 7, 2021 at 10:23 AM Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru> wrote: > > > > On 7/7/21 10:39 AM, David Marchand wrote: > > > On Tue, Jul 6, 2021 at 10:36 AM Andrew Rybchenko > > > <andrew.rybche...@oktetlabs.ru> wrote: > > >> > > >> @David, could you take a look at the ABI breakage warnings for > > >> the patch. May we ignore it since ABI looks backward > > >> compatible? Or should be marked as a minor change ABI > > >> which is backward compatible with DPDK_21? > > > > > > The whole eth_dev_shared_data area has always been reset to 0 at the > > > first port allocation in a dpdk application life. > > > Subsequent calls to rte_eth_dev_release_port() reset every port > > > eth_dev->data to 0. > > > > > > This bit flag is added in a hole of the structure, and it is > > > set/manipulated internally of ethdev. > > > > > > So unless the application was doing something nasty like highjacking > > > this empty hole in the structure, I see no problem with the change wrt > > > ABI. > > > > > > > > > I wonder if libabigail is too strict on this report. > > > Or maybe there is some extreme consideration on what a compiler could > > > do about this hole... > > > > I was wondering if it could be any specifics related to big- > > little endian vs bit fields placement, but throw the idea > > away... > > After some discussion offlist with (fairly busy ;-)) Dodji, the report > here is a good warning. > > But it looks we have an issue with libabigail not properly computing > bitfields offsets. > I just opened a bz for tracking > https://sourceware.org/bugzilla/show_bug.cgi?id=28060 > > This is problematic, as the following rule does not work: > > +; Ignore bitfields added in rte_eth_dev_data hole > +[suppress_type] > + name = rte_eth_dev_data > + has_data_member_inserted_between = {offset_after(lro), > offset_of(rx_queue_state)} > > On the other hand, a (wrong) rule with "has_data_member_inserted_at = > 2" (2 being the wrong offset you can read in abidiff output) works. > > This might force us to waive all changes to rte_eth_dev_data... not > that I am happy about it.
We are not going to do other changes until 21.11, so it could be fine.
