On Fri, Oct 15, 2021 at 12:42 PM Dmitry Kozlyuk <dkozl...@nvidia.com> wrote: > > a/lib/mempool/rte_mempool.c b/lib/mempool/rte_mempool.c index > > 8d5f99f7e7..27d197fe86 100644 > > --- a/lib/mempool/rte_mempool.c > > +++ b/lib/mempool/rte_mempool.c > > @@ -802,6 +802,7 @@ rte_mempool_cache_free(struct rte_mempool_cache > > *cache) > > | MEMPOOL_F_SC_GET \ > > | MEMPOOL_F_POOL_CREATED \ > > | MEMPOOL_F_NO_IOVA_CONTIG \ > > + | MEMPOOL_F_NON_IO \ > > I wonder why CREATED and NON_IO should be listed here: > they are not supposed to be passed by the user, > which is what MEMPOOL_KNOWN_FLAGS is used for. > The same question stands for the test code. > Could you confirm your suggestion?
There was no distinction in the API for valid flags so far, and indeed I did not pay attention to MEMPOOL_F_POOL_CREATED and its internal aspect. (That's the problem when mixing stuff together) We could separate internal and exposed flags in different fields, but it seems overkill. It would be seen as an API change too, if application were checking for this flag. So let's keep this as is. As you suggest, we should exclude those internal flags from KNOWN_FLAGS (probably rename it too), and we will have to export this define for the unit test since the check had been written with contiguous valid flags in mind. If your new flag is internal only, I agree we must skip it. I'll prepare a patch for mempool. -- David Marchand
