> [...] > > +#define MEMPOOL_F_NON_IO 0x0040 /**< Not used for device IO > (DMA). */ > > Doesn't it imply MEMPOOL_F_NO_IOVA_CONTIG?
Let's leave this explicit. NO_IOVA_CONFIG could result in MEMZONE_IOVA_CONTIG (although it doesn't now), which can affect how many pages are used, which may affect performance due to TLB caches. > Shouldn't it reject mempool population with not RTE_BAD_IOVA iova > parameter? > > I see that it is just a hint, but just trying to make full picture consistent. > > As the second thought: isn't iova==RTE_BAD_IOVA sufficient as a hint? 1. It looks true that if RTE_BAD_IOVA is used, we can infer it's a non-IO mempool. 2. The new flag is needed or at least handly, because otherwise to check this property of a mempool, but how? Allocating a test mbuf is doable but looks like a hack. Or we can pass this information to the callback, complicating its signature. Do you think it's better? 3. Theoretically, user may want to use mempools for objects that are used for IO, but not with DPDK. In this case IOVA will be valid, but the flag can also be set. So I'd keep the flag and also infer it for RTE_BAD_IOVA, but allow normal IOVA. What do you think?
