rte_event_dev_xstats_reset id type

Thomas Monjalon thomas at monjalon.net
Wed Oct 12 17:13:00 CEST 2022


12/10/2022 14:14, Van Haaren, Harry:
> From: Morten Brørup <mb at smartsharesystems.com>
> > From: Van Haaren, Harry [mailto:harry.van.haaren at intel.com]
> > > From: Jerin Jacob <jerinjacobk at gmail.com>
> > > > On Wed, Oct 12, 2022 at 1:40 PM Morten Brørup wrote:
> > > > >
> > > > > Hi Jerin (eventdev maintainer),
> > > >
> > > > + harry.van.haaren at intel.com as the changes in drivers/event/sw.
> > >
> > > Thanks Jerin.
> > >
> > >
> > > > > While looking into bug #1101 [1], I noticed a mix of unsigned int
> > > and uint32_t in
> > > > the test code, which will fail on 64-bit big endian CPUs.
> > >
> > > Aha; that we can fix. I am curious why this isn't found in CI/reported
> > > before.
> > 
> > We probably don't test any 64-bit *big endian* architectures. Just a guess.
> 
> Seems so yes.
> 
> > > > > Specifically, rte_event_dev_xstats_reset() is called with the "ids"
> > > parameter
> > > > pointing to an unsigned int [2], but that parameter is a pointer to
> > > an uint32_t.
> > > > >
> > > > > I think the type of the ids array parameter to
> > > rte_event_dev_xstats_reset() should
> > > > be changed to unsigned int array, like in the other
> > > rte_event_dev_xxx() functions.
> > >
> > > In this case, we have the option to change the type of a variable in a
> > > test-case, or change API and cause API/ABI breakage.
> > 
> > Well.. yes, but I would phrase that last option: Change the API/ABI, so related
> > functions consistently use the same type for the same variable, instead of randomly
> > mixing uint64_t, uint32_t and unsigned int, depending on function.
> 
> Aah ok; I see your point now; there is inconsistent usage of uint32_t/unsigned int
> between the Eventdev APIs itself. Agree this is sub-optimal, and would have been
> nice to have spotted before the Eventdev API was stabilized.
> 
> 
> > Unfortunately, these functions are not marked experimental, so breaking API/ABI is
> > hard to do. :-(
> 
> Agreed again.

22.11 is a breaking release,
and changing type in the API is not much impactful,
so that's something you can change now,
or be quiet forever :)





More information about the dev mailing list