[PATCH v2 1/2] eal: provide leading and trailing zero bit count abstraction

[Tyler Retzlaff]

On Thu, Jan 05, 2023 at 09:27:12AM -0800, Tyler Retzlaff wrote:
> On Thu, Jan 05, 2023 at 09:23:49AM -0800, Tyler Retzlaff wrote:
> > > > oh! not a problem. i'm very keen to catch any mistakes, thought i had
> > > > missed something.
> > > 
> > > I think we should move all bit-related functions together.
> > > Please could you add another patch to your series
> > > moving "ms1b"/"bsf"/"fls" functions in this file?
> > > 
> > > 
> > 
> > okay, so there is already a rte_bitops.h. i guess everything should go
> > there including the leading/trailing count functions instead of adding a
> > new header.
> > 
> > i'll introduce a new patch to the series that gathers the existing
> > functions into rte_bitops.h and place the new functions there too.
> > 
> > thanks
> 
> just as a further follow up, you do understand that this is technically
> an api break?
> 
> moving functions from rte_common.h to rte_bitops.h will make translation
> units that included only rte_common.h but used these functions will
> fail to compile without being updated to include rte_bitops.h.
> 
> anyway, i'll submit v3 with this change anyway.

so when attempting to do this it became immediately obvious that moving
just the bit op functions out is going to create a circular dependency
between rte_common.h, rte_bitops.h

once the bit ops are moved out of common there are still other inline
functions that remain in comman that require bringing bitops back in,
but bitops depends on common.

my compromise will be to break log2 and pow2 inline functions into their
own files to break the cycle (common no longer depends on bitops). i'll
submit patches for this but it ends up touching a lot more of the
tree to add back includes for log/pow inline use.

alternatively i can just not move the remaining bit manipulation
functions, let me know which is preferred.

thanks