On Wed, Aug 16, 2023 at 01:40:41PM +0200, David Marchand wrote: > On Wed, Aug 16, 2023 at 1:15 PM David Marchand > <david.march...@redhat.com> wrote: > > > > On Wed, Aug 16, 2023 at 1:02 PM Bruce Richardson > > <bruce.richard...@intel.com> wrote: > > > These lines here seem to be exposing a bug in the mempool unit tests for > > > shared builds, which is why we have a CI failure. > > > > > > The mempool unit tests use the mempool "create_empty" API, and then call > > > the populate APIs to finish setting up the mempool. However, the > > > create_empty API does not explicitly configure a particular set of mempool > > > ops for the new mempool, leaving the ops field at 0. This means that > > > unless > > > the app explicitly sets other ops, the mempool will use the ops from > > > whatever driver registers itself first. This occurs even when the driver > > > is > > > unsuitable, e.g. on my Intel system, the dpaa2 is first on the list, > > > leading to failures in setting up and using the mempool. > > > > Hum, it sounds like a bug to me. > > The dpaa2 driver should not be registered as the default (or here, > > default platform) mempool. > > Other mempool drivers ensure that required hw is available, I guess > > dpaa2 is missing some check. > > Ok, re-reading your last comment, I agree it looks like an issue in > the unit test itself. > Copying Olivier. > No, I think it's not a bug in the test, but rather in the mempool. Unfortunately, I think the concept of the "default" driver for mempools seems to exist only when using the mbuf library to create mempools. Even then, the default mempool is different from what the first entry in the list is. That's the fundamental issue here, we are using the zero-eth entry in the ops list, rather than a default one.
/Bruce
