From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id E53C68DB3 for ; Tue, 12 Jan 2016 12:44:47 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 12 Jan 2016 03:44:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,557,1444719600"; d="scan'208";a="858840009" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.28]) ([10.237.221.28]) by orsmga001.jf.intel.com with ESMTP; 12 Jan 2016 03:44:44 -0800 To: Pavel Fedin References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-3-git-send-email-jianfeng.tan@intel.com> <5694C36D.2040006@intel.com> <00d501d14d20$930c8ae0$b925a0a0$@samsung.com> <5694D9E9.6060704@intel.com> <00de01d14d28$7c2eaf80$748c0e80$@samsung.com> <5694DE7C.4050206@intel.com> From: Sergio Gonzalez Monroy Message-ID: <5694E72B.9040604@intel.com> Date: Tue, 12 Jan 2016 11:44:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5694DE7C.4050206@intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, nakajima.yoshihiro@lab.ntt.co.jp, ann.zhuangyanying@huawei.com, "'Michael S. Tsirkin'" Subject: Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info 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: Tue, 12 Jan 2016 11:44:48 -0000 On 12/01/2016 11:07, Sergio Gonzalez Monroy wrote: > Hi Pavel, > > On 12/01/2016 11:00, Pavel Fedin wrote: >> Hello! >> >>>> BTW, i'm still unhappy about ABI breakage here. I think we could >>>> easily add --shared-mem Could you elaborate a bit more on your concerns regarding ABI breakage ? >>> option, which would simply change mapping mode to SHARED. So, we >>> could use it with both >>> hugepages (default) and plain mmap (with --no-hugepages). >>> >>> You mean, use "--no-hugepages --shared-mem" together, right? >> Yes. This would be perfectly backwards-compatible because. > > So are you suggesting to not introduce --single-file option but > instead --shared-mem? > AFAIK --single-file was trying to workaround the limitation of just > being able to map 8 fds. > My bad, I misread the posts. Jianfeng pointed out that you are suggesting to have --shared-mem to have same functionality with or without hugepages. Sergio > Sergio >> Kind regards, >> Pavel Fedin >> Senior Engineer >> Samsung Electronics Research center Russia >> >> >