Re: [dpdk-dev] [PATCH v3 2/4] mempool: add non-IO flag

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

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?
>