From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com [209.85.192.173]) by dpdk.org (Postfix) with ESMTP id C17AA919F for ; Fri, 22 Jan 2016 04:23:12 +0100 (CET) Received: by mail-pf0-f173.google.com with SMTP id 65so34214653pff.2 for ; Thu, 21 Jan 2016 19:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=igel-co-jp.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Dy6R26dYmIeisXu224KmP0HaK8j2+DmWSmxs/yPIM7w=; b=JpW1YsgySqlKxj9By30lcBA3HHhCuk5aKBjmBlyDgqRRAFfXMP+8JMmJmGODQLs6Ym TkqN9gPcHyMaO1qGHvQox+oA6i/z/xyeJPxZ+mtaWr8kWvqhwGbIKPwgfx9m1v1G2/vK LlNOxdb7n8LqFpnFMYIdxq8smedxlbpyYO3/If1fTZVZGJ57R2C5cCr2jKB8pO0aA+BH dQ+7NKTDfVeAiv+sUKoNBmIhHQo97wVaH9cgz9bmN7X1pZvnZZYpgB2Zta0S/Y2MocVD NN5+2jq0aX+zVWrvjriZoVz7yUumCVALT9p5oH3I6YJcqN1xFA7fqihJbYVeHRN9nf26 tSUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=Dy6R26dYmIeisXu224KmP0HaK8j2+DmWSmxs/yPIM7w=; b=nLs8A8UKCsw4f9N+moYh4ZSezO36HcLNNwpQNDB7JZP94cu5zUPgyskjj1okLGapLR BESQ3ykuD4JfKpgskW9Yo8N4uruJ4LRbsCzLdUYsY+RoJzfKbgknFVRJEnjSeynMOVeB 5tDYO/YblB9G1kFCWPDwaZ/b3hwswQr4BFq+HE6SJqxnfMdfsg+fEcbqo1X3ZXIseLO7 hI9FCFY0kCg2ouAAMiyRFAjfC1X3LkU61XTawCXp5OcAeyYI4Id82HOtQ3N9hQq5qpLL 3ISunMDQh1EFGvpghQ3MMOtjqZUeMGI7Oh/po6yAgkMH5+DBU7JeYM8gbw9fOKHbsqTn A89Q== X-Gm-Message-State: AG10YOSi+f9jY/Wp/YO4l5mV/X6XqkzfZH/NEi81bBHOS7xM0wfd968mWMNUtM1k3sc8Tw== X-Received: by 10.98.13.77 with SMTP id v74mr1156932pfi.162.1453432992191; Thu, 21 Jan 2016 19:23:12 -0800 (PST) Received: from [10.16.129.101] (napt.igel.co.jp. [219.106.231.132]) by smtp.googlemail.com with ESMTPSA id 7sm5552260pfn.89.2016.01.21.19.23.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 19:23:11 -0800 (PST) To: "Tan, Jianfeng" , dev@dpdk.org References: <1453108389-21006-2-git-send-email-mukawa@igel.co.jp> <1453374478-30996-5-git-send-email-mukawa@igel.co.jp> <56A18958.7070202@intel.com> <56A18EFE.5050600@intel.com> From: Tetsuya Mukawa X-Enigmail-Draft-Status: N1110 Message-ID: <56A1A09F.5020006@igel.co.jp> Date: Fri, 22 Jan 2016 12:23:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A18EFE.5050600@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC PATCH 4/5] EAL: Add new EAL "--shm" option. X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 03:23:13 -0000 On 2016/01/22 11:07, Tan, Jianfeng wrote: > Hi Tetsuya, > > On 1/22/2016 9:43 AM, Tan, Jianfeng wrote: >> Hi Tetsuya, >> >> On 1/21/2016 7:07 PM, Tetsuya Mukawa wrote: >>> 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 >>> --- >>> 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(+) >>> >> > ... >>> + 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