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. -- David Marchand
