Thread (120 messages) flat view 120 messages, 7 authors, 2016-06-07

Re: [RFC PATCH 4/5] EAL: Add new EAL "--shm" option.

From: Tetsuya Mukawa <hidden>
Date: 2016-01-22 03:23:12

On 2016/01/22 11:07, Tan, Jianfeng wrote:
Hi Tetsuya,

On 1/22/2016 9:43 AM, Tan, Jianfeng wrote:
quoted
Hi Tetsuya,

On 1/21/2016 7:07 PM, Tetsuya Mukawa wrote:
quoted
This is a temporary patch to get EAL memory under 16T(1 << 44).

The patch adds new EAL "--shm" option. If the option is specified,
EAL will allocate one file from hugetlbfs. This memory is for sharing
memory between DPDK applicaiton and QEMU ivhsmem device.

Signed-off-by: Tetsuya Mukawa <redacted>
---
  lib/librte_eal/common/eal_common_options.c |  5 ++
  lib/librte_eal/common/eal_internal_cfg.h   |  1 +
  lib/librte_eal/common/eal_options.h        |  2 +
  lib/librte_eal/common/include/rte_memory.h |  5 ++
  lib/librte_eal/linuxapp/eal/eal_memory.c   | 76
++++++++++++++++++++++++++++++
  5 files changed, 89 insertions(+)
...
quoted
quoted
+    vaddr = mmap((void *)(1ULL << 43), size, PROT_READ | PROT_WRITE,
+            MAP_SHARED | MAP_FIXED, fd, 0);
+    if (vaddr != MAP_FAILED) {
+        memset(vaddr, 0, size);
+        *pfd = fd;
+    }
I'm not sure if hard-coded way is good enough. It's known that kernel
manages VMAs using red-black tree, but I don't know if kernel
allocates VMA from low address to high address (if yes, can we
leverage this feature?).
Hi Jianfeng,

Thanks for comments.
Yes, this "--shm" patch is totally crap, and this patch series is just
for describing how to implement an access method abstraction layer and
how to use it. Main purpose of this patch series is this.

But without this "--shm" patch, if someone wants to test my patch, they
cannot do it.
Because of this, I just involved this patch.
I guess you have already implemented almost same feature in EAL, I will
use it when I submit my container patch.
If we can agree how to implement the access method abstraction layer, I
will submit my container patch separately.
A little more:it seems that kernel uses
arch_get_unmapped_area_topdown() -> unmapped_area_topdown() to do
that, which starts at mm->highest_vm_end. If this value bigger than
(1ULL << 44)?
Yes, I specified MAP_FIXED as mmap parameter.
Then arch_get_unmapped_area_topdown() will not go "unmapped_area_topdown()".
Anyway, we will need to check /proc/self/maps to determine where we can
mmap the memory.

Thanks,
Tetsuya
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help