[dpdk-dev] [PATCH v8 1/3] vfio: revert changes for map contiguous areas in one go

[Burakov, Anatoly]

On 05-Mar-21 3:50 PM, Nithin Dabilpuram wrote:
> On Fri, Mar 05, 2021 at 01:54:34PM +0000, Burakov, Anatoly wrote:
>> On 05-Mar-21 7:50 AM, David Marchand wrote:
>>> On Fri, Jan 15, 2021 at 8:33 AM Nithin Dabilpuram
>>> <ndabilpuram at marvell.com> wrote:
>>>>
>>>> In order to save DMA entries limited by kernel both for externel
>>>> memory and hugepage memory, an attempt was made to map physically
>>>> contiguous memory in one go. This cannot be done as VFIO IOMMU type1
>>>> does not support partially unmapping a previously mapped memory
>>>> region while Heap can request for multi page mapping and
>>>> partial unmapping.
>>>> Hence for going back to old method of mapping/unmapping at
>>>> memseg granularity, this commit reverts
>>>> commit d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
>>>>
>>>> Also add documentation on what module parameter needs to be used
>>>> to increase the per-container dma map limit for VFIO.
>>>>
>>>> Fixes: d1c7c0cdf7ba ("vfio: map contiguous areas in one go")
>>>> Cc: anatoly.burakov at intel.com
>>>> Cc: stable at dpdk.org
>>>>
>>>> Signed-off-by: Nithin Dabilpuram <ndabilpuram at marvell.com>
>>>> Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>
>>>> Acked-by: David Christensen <drc at linux.vnet.ibm.com>
>>>
>>> There is a regression reported in bz: https://bugs.dpdk.org/show_bug.cgi?id=649
>>>
>>> I assigned it to Anatoly for now.
>>> Nithin, can you have a loo too?
>>>
>>> Thanks.
>>>
>>>
>>
>> I've responded on the bug tracker as well, but to repeat it here: this is
>> not a regression, this is intended behavior. We cannot do anything about
>> this.
> 
> To add, for test case to pass, either limits have to be increased, or use "--mp-alloc=xmemhuge"
> instead of "--mp-alloc=xmem" which is forcing system page size or reduce total mbuf count
> to reduce page count.
> 

Technically, one is not a replacement for the other, so the correct way 
to handle it is to increase the limits, not using xmemhuge.

-- 
Thanks,
Anatoly