[dpdk-dev] [PATCH 8/8] mem: support using memfd segments for in-memory mode
Burakov, Anatoly
anatoly.burakov at intel.com
Fri Aug 24 10:56:12 CEST 2018
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 at intel.com>
>> To: dev at dpdk.org
>> CC: tiwei.bie at intel.com, ray.kinsella at intel.com, zhihong.wang at intel.com,
>> maxime.coquelin at redhat.com, kuralamudhan.ramakrishnan at 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 at 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
More information about the dev
mailing list