From mboxrd@z Thu Jan  1 00:00:00 1970
From: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Subject: Re: [PATCH 2/4] mem: add API to obstain memory-backed
 file info
Date: Tue, 12 Jan 2016 11:44:43 +0000
Message-ID: <5694E72B.9040604@intel.com>
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>
 <CAGSMBPNeAt9a3kpiJmP=zVwEhoHeBbLfe7baBq8msfitqAb6+A@mail.gmail.com>
 <5694C36D.2040006@intel.com> <00d501d14d20$930c8ae0$b925a0a0$@samsung.com>
 <5694D9E9.6060704@intel.com> <00de01d14d28$7c2eaf80$748c0e80$@samsung.com>
 <5694DE7C.4050206@intel.com>
Mime-Version: 1.0
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'" <mst@redhat.com>
To: Pavel Fedin <p.fedin@samsung.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id E53C68DB3
 for <dev@dpdk.org>; Tue, 12 Jan 2016 12:44:47 +0100 (CET)
In-Reply-To: <5694DE7C.4050206@intel.com>
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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
>>
>>
>