On 10/12/21 3:40 PM, Dmitry Kozlyuk wrote: >> [...] >>> +#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.
It sounds like a usage of a side effect of MEMPOOL_F_NO_IOVA_CONTIG absence. It does not sound good. > >> 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? mempool knows it when the mempool is populated. So, it can just set the flag itself. > 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. It sounds very artificial. Also in this case I guess MEMPOOL_F_NON_IO should be clear anyway. > > So I'd keep the flag and also infer it for RTE_BAD_IOVA, but allow normal > IOVA. > What do you think? >
