From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 726E25398 for ; Mon, 18 Feb 2019 13:21:06 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2019 04:21:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,384,1544515200"; d="scan'208";a="145201827" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.110]) ([10.237.220.110]) by fmsmga004.fm.intel.com with ESMTP; 18 Feb 2019 04:21:03 -0800 To: Shahaf Shuler , Alejandro Lucero Cc: Yongseok Koh , Thomas Monjalon , Ferruh Yigit , "nhorman@tuxdriver.com" , Gaetan Rivet , dev References: <81f4bbef-8d6a-d845-eb07-966bbccf4849@intel.com> From: "Burakov, Anatoly" Message-ID: <991e35df-2aa5-3bb9-f505-dd17f71e8cab@intel.com> Date: Mon, 18 Feb 2019 12:21:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for external memory 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: , X-List-Received-Date: Mon, 18 Feb 2019 12:21:07 -0000 On 17-Feb-19 6:18 AM, Shahaf Shuler wrote: > Thursday, February 14, 2019 6:20 PM, Burakov, Anatoly: >> Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for >> external memory >> >> On 14-Feb-19 1:28 PM, Shahaf Shuler wrote: >>> Thursday, February 14, 2019 12:19 PM, Burakov, Anatoly: >>>> Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping for >>>> external memory >>>> >>>> On 13-Feb-19 7:24 PM, Shahaf Shuler wrote: >>>>> Wednesday, February 13, 2019 1:43 PM, Alejandro Lucero: >>>>>> Subject: Re: [dpdk-dev] [PATCH 0/6] introduce DMA memory mapping >>>>>> for external memory >>>>>> > > [...] > >>> >>> If we are going to force all to use the extmem, then there is no need w/ >> this API. we can have the PMDs to register when the memory is registered. >>> We can just drop the vfio_dma_map APIs and that's it. >>> >> >> Well, whether we needed it or not is not really my call, but what i can say is >> that using extmem_register is _necessary_ if you're going to use the PMD's. >> You're right, we could just map memory for DMA at register time - that >> would save one API call to get the memory working. It makes it a bit weird >> semantically, but i think we can live with that :) > > This was not my suggestion 😊. I don't think the register API should do the mapping as well. > My thoughts were on one of the two options: > 1. have the series I propose here, and enable the user to work with memory managed outside of DPDK. Either force the user to call rte_extmem_register before the mapping or devices which needs memory to be also registered in the DPDK system can fail the mapping. > 2. not providing such option to application, and forcing applications to populate a socket w/ external memory. > > I vote for #1. I too think #1 is better - we want this to be a valid use case. Allowing such usage in the first place is already gracious enough - all we ask in return is one extra API call, to politely let DPDK know that this memory exists and is going to be used for DMA :) Also, having the memory registered will also allow us to refuse mapping if it cannot be found in DPDK maps - if rte_virt2memseg returns NULL, that means extmem_register was not called. I.e. we can _enforce_ usage of extmem_register, which i believe is a good thing for usability. > >> >> -- >> Thanks, >> Anatoly -- Thanks, Anatoly