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

[David Marchand <david.marchand@redhat.com>]

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.


-- 
David Marchand