From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E1523A046B for ; Tue, 25 Jun 2019 15:38:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E8BE51B9FE; Tue, 25 Jun 2019 15:38:42 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id DA15F1B9C6 for ; Tue, 25 Jun 2019 15:38:40 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jun 2019 06:38:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,416,1557212400"; d="scan'208";a="359955608" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.101]) ([10.237.220.101]) by fmsmga005.fm.intel.com with ESMTP; 25 Jun 2019 06:38:38 -0700 To: Jerin Jacob Kollanukkaran , Vamsi Krishna Attunuru , "dev@dpdk.org" Cc: "ferruh.yigit@intel.com" , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" References: <20190422061533.17538-1-kirankumark@marvell.com> <20190625035700.2953-1-vattunuru@marvell.com> <51e1b2c8-4290-c9b5-701f-5be55e763425@intel.com> <4906aad7-47a2-6707-cf69-417043c46c8c@intel.com> From: "Burakov, Anatoly" Message-ID: <7bfd30cf-aec6-9fd3-00b0-ed8964849869@intel.com> Date: Tue, 25 Jun 2019 14:38:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <4906aad7-47a2-6707-cf69-417043c46c8c@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in KNI X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 25-Jun-19 12:30 PM, Burakov, Anatoly wrote: > On 25-Jun-19 12:15 PM, Jerin Jacob Kollanukkaran wrote: >>> -----Original Message----- >>> From: dev On Behalf Of Burakov, Anatoly >>> Sent: Tuesday, June 25, 2019 3:30 PM >>> To: Vamsi Krishna Attunuru ; dev@dpdk.org >>> Cc: ferruh.yigit@intel.com; olivier.matz@6wind.com; >>> arybchenko@solarflare.com >>> Subject: Re: [dpdk-dev] [PATCH v6 0/4] add IOVA = VA support in KNI >>> >>> On 25-Jun-19 4:56 AM, vattunuru@marvell.com wrote: >>>> From: Vamsi Attunuru >>>> >>>> ---- >>>> V6 Changes: >>>> * Added new mempool flag to ensure mbuf memory is not scattered across >>>> page boundaries. >>>> * Added KNI kernel module required PCI device information. >>>> * Modified KNI example application to create mempool with new mempool >>>> flag. >>>> >>> Others can chime in, but my 2 cents: this reduces the usefulness of >>> KNI because >>> it limits the kinds of mempools one can use them with, and makes it >>> so that the >>> code that works with every other PMD requires changes to work with KNI. >> >> # One option to make this flag as default only for packet mempool(not >> allow allocate on page boundary). >> In real world the overhead will be very minimal considering Huge page >> size is 1G or 512M >> # Enable this flag explicitly only IOVA = VA mode in library. Not >> need to expose to application >> # I don’t think, there needs to be any PMD specific change to make KNI >> with IOVA = VA mode >> # No preference on flags to be passed by application vs in library. >> But IMO this change would be >> needed in mempool support KNI in IOVA = VA mode. >> > > I would be OK to just make it default behavior to not cross page > boundaries when allocating buffers. This would solve the problem for KNI > and for any other use case that would rely on PA-contiguous buffers in > face of IOVA as VA mode. > > We could also add a flag to explicitly allow page crossing without also > making mbufs IOVA-non-contiguous, but i'm not sure if there are use > cases that would benefit from this. On another thought, such a default would break 4K pages in case for packets bigger than page size (i.e. jumbo frames). Should we care? > >> >> >>> >>> -- >>> Thanks, >>> Anatoly > > -- Thanks, Anatoly