On Fri, Oct 15, 2021 at 01:41:40PM +0200, David Marchand wrote: > 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
I suggest RTE_MEMPOOL_VALID_USER_FLAGS for the name > 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 >
