Re: [dpdk-dev] [PATCH 8/8] mem: support using memfd segments for in-memory mode

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 24-Aug-18 5:39 AM, Jerin Jacob wrote:
> -----Original Message-----
>> Date: Thu, 23 Aug 2018 17:59:55 +0100
>> From: Anatoly Burakov <anatoly.burakov@intel.com>
>> To: dev@dpdk.org
>> CC: tiwei.bie@intel.com, ray.kinsella@intel.com, zhihong.wang@intel.com,
>>   maxime.coquelin@redhat.com, kuralamudhan.ramakrishnan@intel.com
>> Subject: [dpdk-dev] [PATCH 8/8] mem: support using memfd segments for
>>   in-memory mode
>> X-Mailer: git-send-email 1.7.0.7
>>
>>
>> Enable using memfd-created segments if supported by the system.
>>
>> This will allow having real fd's for pages but without hugetlbfs
>> mounts, which will enable in-memory mode to be used with virtio.
>>
>> The implementation is mostly piggy-backing on existing real-fd
>> code, except that we no longer need to unlink any files or track
>> per-page locks in single-file segments mode, because in-memory
>> mode does not support secondary processes anyway.
>>
>> We move some checks from EAL command-line parsing code to memalloc
>> because it is now possible to use single-file segments mode with
>> in-memory mode, but only if memfd is supported.
>>
>> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
>> ---
>>   lib/librte_eal/common/eal_common_options.c |   6 +-
>>   lib/librte_eal/linuxapp/eal/eal_memalloc.c | 265 ++++++++++++++++++---
>>   2 files changed, 235 insertions(+), 36 deletions(-)
>>
>>
>> +static inline uint32_t
>> +bsf64(uint64_t v)
>> +{
>> +       return (uint32_t)__builtin_ctzll(v);
>> +}
>> +
>> +static inline uint32_t
>> +log2_u64(uint64_t v)
>> +{
>> +       if (v == 0)
>> +               return 0;
>> +       v = rte_align64pow2(v);
>> +       return bsf64(v);
>> +}
>> +
> 
> Can we move this to lib/librte_eal/common/include/rte_common.h?
> It has already rte_log2_u32()
> 
> 

We can (and i will), unfortunately we cannot do it in this release, due 
to there already being an rte_bsf64 in rte_bitmap.h, and 
changing/renaming that API will require a deprecation notice. So, this 
change will be for 19.02.

-- 
Thanks,
Anatoly