Re: [dpdk-dev] [PATCH V2] ethdev: add dev configured flag

[Thomas Monjalon <thomas@monjalon.net>]

07/07/2021 11:36, David Marchand:
> On Wed, Jul 7, 2021 at 10:23 AM Andrew Rybchenko
> <andrew.rybchenko@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.rybchenko@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.