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. -- David Marchand
