From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by dpdk.org (Postfix) with ESMTP id D76A0567C for ; Thu, 25 Aug 2016 16:19:06 +0200 (CEST) Received: by mail-oi0-f51.google.com with SMTP id f189so68268078oig.3 for ; Thu, 25 Aug 2016 07:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qV0Vhjhuav4WpJWk1LrroAovVH4ioFqh8iOP/3ou8b0=; b=BN9xt5SwxBQLAdhydZSkHjSzOQt1akOorY0tk1NY2XiXiqgHZiv5eUhAro9K9YACmS IjLYFoKxOWy+7qM0xZ7fEXMYQJCRUc836Gwg6lFrYOVuwSzqj0Am7PBXWRyAKY6nUWIZ jwZaNgnkjpzg07ql1F9ZLZyUfgiNOCAHxIB8ZahB+GcEZWMk4scJxrGCy1JxpVe4BjmW 5178MN/8jGs5n7CekGEOX4V0/q1+L2GkbZy1LnXt7kJ6acHtAowYe3m2dHGJG+Ly2gER MVpjIcq0blshSPXMCyoX/QnKO2VIYUan94EhyjMfInlMbIQJN79KvJB399wRqjXlxbyh Duvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qV0Vhjhuav4WpJWk1LrroAovVH4ioFqh8iOP/3ou8b0=; b=JRRdNEp5ZEL+eOYrLfpbul3/2vjv1ggftWqXvv5ZIGGen0u/VrrC5hk9wv2JOMNgr6 xP2iZfJ7TgOOsT56fa5NVVesULXvtIY4lGP54evcfeAIv5uUHuN+g6p6NKN/wL9cL+aN oIg8fClydRYkeScEzz+s4W7Z8lmc3zEqnY9UChD7KqQ+XD1hQo84kPpLa+uMi8TfcJDY XCn13qixJogFgm+werq1da1B9Fu4FgBFr02etNtnMJhmB6ovWg4eE07zyc/WotLs98q9 sd2wsJ31yc99+6EwD3wK41SrCSLnm0G09E2m7RONXN9DmwPxVvmKf9SNDN31GNoPlg2l TdxQ== X-Gm-Message-State: AEkooutbETM4D4sxbeELvOoNMA9/XmjMyAFLVbjNJfHOalhpbEHSmsgnr659LriBc7s8ORqyc/kVlUSzjawyhA== X-Received: by 10.202.175.201 with SMTP id y192mr6140777oie.137.1472134746294; Thu, 25 Aug 2016 07:19:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.192.33 with HTTP; Thu, 25 Aug 2016 07:19:05 -0700 (PDT) In-Reply-To: <57BEF7EB.5000606@intel.com> References: <57A369E2.6070506@intel.com> <57AB072A.5050206@intel.com> <57BEF7EB.5000606@intel.com> From: Gopakumar Choorakkot Edakkunni Date: Thu, 25 Aug 2016 07:19:05 -0700 Message-ID: To: Ferruh Yigit Cc: dev@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 14:19:07 -0000 Thank you Ferruh, I will give this a spin over the weekend and let you know. Rgds, Gopa. On Thu, Aug 25, 2016 at 6:51 AM, Ferruh Yigit wrote: > On 8/10/2016 11:51 AM, Ferruh Yigit wrote: > > 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; > > Hi Gopakumar, > > Off the list. > > Any chance to test this? > > Thanks, > ferruh > >