From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: dpdk 16.07, issues with rte_mempool_create and rte_kni_alloc() Date: Thu, 4 Aug 2016 17:14:26 +0100 Message-ID: <57A369E2.6070506@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit To: Gopakumar Choorakkot Edakkunni , dev@dpdk.org, olivier.matz@6wind.com Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 10BDF2BE0 for ; Thu, 4 Aug 2016 18:14:28 +0200 (CEST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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. Regards, ferruh