[dpdk-dev] [RFC] net/virtio-user: avoid parsing process mappings

[Burakov, Anatoly]

On 28-Aug-18 9:42 AM, Tiwei Bie wrote:
> On Tue, Aug 28, 2018 at 09:12:38AM +0100, Burakov, Anatoly wrote:
>> On 28-Aug-18 8:53 AM, Tiwei Bie wrote:
> [...]
>>>    
>>> -	for (i = 0; i < num; ++i) {
>>> -		mr = &msg->payload.memory.regions[i];
>>> -		mr->guest_phys_addr = huges[i].addr; /* use vaddr! */
>>> -		mr->userspace_addr = huges[i].addr;
>>> -		mr->memory_size = huges[i].size;
>>> -		mr->mmap_offset = 0;
>>> -		fds[i] = open(huges[i].path, O_RDWR);
>>> +	start_addr = (uint64_t)(uintptr_t)ms->addr;
>>> +	end_addr = start_addr + ms->len;
>>> +
>>> +	/*
>>> +	 * XXX workaround!
>>> +	 *
>>> +	 * For --single-file-segments case, offset should be:
>>> +	 * offset = rte_fbarray_find_idx(&msl->memseg_arr, ms) * msl->page_sz;
>>> +	 *
>>> +	 * But it's not true for non-single-file-segments case.
>>> +	 *
>>> +	 * This is a temporary workaround which assumes the file will
>>> +	 * also be mapped from the beginning in --single-file-segments
>>> +	 * case. It should be replaced when we have a memory API to
>>> +	 * get the offset.
>>
>> Yes, this is an unfortunate consequence of having split personalities in
>> memory subsystem. A good solution would be to just deprecate
>> non-single-file segments mode and always use it, but we cannot do that
>> because we support kernel versions that do not support fallocate() on
>> hugetlbfs (and it still leaves legacy mem mode, which effectively
>> behaves like non-single-file segments as far as virtio is concerned).
>>
>> How about we add this API in v2 for seg fd patchset?
> 
> Sure, thanks!
> 
> Besides, I saw another minor issue. When --legacy-mem
> and --single-file-segments are both specified, the EAL
> init doesn't fail, but fd can't be got successfully.
> 

I'll have to look into this, because as far as i recall, i've submitted 
a patch specifically prohibiting legacy mem combined with single file 
segments. I'll double check though. Thanks for testing!

-- 
Thanks,
Anatoly