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. > > In v6 of this set, I intend to fix this, by changing the create empty API > to explicitly set the ring driver as default for new mempools. It's the > most likely to work for common cases. -- David Marchand
