From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
 by dpdk.org (Postfix) with ESMTP id CDB19568A
 for <dev@dpdk.org>; Wed, 10 Aug 2016 12:51:28 +0200 (CEST)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by orsmga102.jf.intel.com with ESMTP; 10 Aug 2016 03:51:28 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.28,499,1464678000"; d="scan'208";a="1011818394"
Received: from jyeoh4-mobl1.gar.corp.intel.com (HELO [10.255.144.149])
 ([10.255.144.149])
 by orsmga001.jf.intel.com with ESMTP; 10 Aug 2016 03:51:25 -0700
To: Gopakumar Choorakkot Edakkunni <gopakumar.c.e@gmail.com>, dev@dpdk.org,
 olivier.matz@6wind.com
References: <CABK1yFCOi4WyBhtOdqvA28-cV03_UHPeSu2oz+xx5Mimb0QKiA@mail.gmail.com>
 <CABK1yFAhLBHEkR_pgi0UwoyWjZdGoRS3BCWR0mAaN5J=gRm3Qg@mail.gmail.com>
 <57A369E2.6070506@intel.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <57AB072A.5050206@intel.com>
Date: Wed, 10 Aug 2016 11:51:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <57A369E2.6070506@intel.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [dpdk-dev] dpdk 16.07,
 issues with rte_mempool_create and rte_kni_alloc()
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
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>
X-List-Received-Date: Wed, 10 Aug 2016 10:51:29 -0000

Hi Gopakumar,

On 8/4/2016 5:14 PM, Ferruh Yigit wrote:
> On 8/1/2016 10:19 PM, Gopakumar Choorakkot Edakkunni wrote:
>> Well, for my purpose I just ended up creating a seperate/smaller pool
>> earlier during bootup to try to guarantee its from one memseg.
>>
>> But I am assuming that this KNI restriction is something thats "currently"
>> not fixed and is "fixable" ? 
> 
> 
>> Any ideas on what the summary of the reason
>> for this restriction is - I was gonna check if I can fix that
> 
> KNI expects all mbufs are from a physically continuous memory. This is
> because of current address translation implementation.
> 
> mbufs allocated in userspace and accessed from both user and kernel
> space, so mbuf userspace virtual address needs to be converted into
> kernelspace virtual address.
> 
> Currently this address translation done by first calculating an offset
> between virtual addresses using first filed of mempool, later applying
> same offset to all mbufs. This is why all mbufs should be in physically
> continuous memory.
> 
> I think this address translation can be done in different way which can
> remove the restriction, but not sure about the effect of the
> performance. I will send a patch for this.

I have sent a patch to remove KNI restriction:
http://dpdk.org/dev/patchwork/patch/15171/

Can you please test this patch with a mempool with multiple memzone?
You need to remove following check in KNI manually:
    if (mp->nb_mem_chunks != 1)
        goto kni_fail;

Thanks,
ferruh