David Marchand <david.march...@redhat.com> writes:
> On Wed, Feb 28, 2024 at 3:04 PM Dodji Seketeli <do...@redhat.com> wrote:
>> > Btw, I see no way to suppress this (except a global [suppress_type]
>> > name = rte_mbuf)...
>>
>> Right.
>>
>> To avoid having subsequent changes to that type from being "overly"
>> suppressed, maybe do something like:
>>
>> [suppress_type]
>> name = rte_mbuf
>> has_size_change = no
>> has_data_member = {cacheline0, rearm_data, rx_descriptor_fields1,
>> cacheline1}
>>
>> That way, only size-impacting changes to struct rte_mbuf in its form
>> that predates this patch would be suppressed, hopefully.
>
> Do you mean, only changes *not* size-impacting would be suppressed?
Yes, of course. Sorry for the typo. You are right.
> This is slightly better than the suppression on the whole rte_mbuf
> object, but it won't catch field reordering iiuc.
Indeed.
>
> On the other hand, now that I try reordering fields (to test this
> suggestion of yours), I get build failures all over the DPDK tree
> because we have many build checks to ensure those fields are at known
> locations...
> So maybe we can relax and just go with the full suppression.
Yes, that would make sense.
Thanks!
--
Dodji
