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

On Wed, Jul 7, 2021 at 10:23 AM Andrew Rybchenko
[off-list ref] wrote:

On 7/7/21 10:39 AM, David Marchand wrote:

quoted

On Tue, Jul 6, 2021 at 10:36 AM Andrew Rybchenko
[off-list ref] wrote:

quoted

@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