From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <anatoly.burakov@intel.com> Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id 726E25398 for <dev@dpdk.org>; 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 <shahafs@mellanox.com>, Alejandro Lucero <alejandro.lucero@netronome.com> Cc: Yongseok Koh <yskoh@mellanox.com>, Thomas Monjalon <thomas@monjalon.net>, Ferruh Yigit <ferruh.yigit@intel.com>, "nhorman@tuxdriver.com" <nhorman@tuxdriver.com>, Gaetan Rivet <gaetan.rivet@6wind.com>, dev <dev@dpdk.org> References: <cover.1550048187.git.shahafs@mellanox.com> <CAD+H9922gjrmwbRr5Qo7cVqvE5DBJj27hvq-+_16GAPjYWbBcg@mail.gmail.com> <AM0PR0502MB3795448496DA4721C809ECE6C3660@AM0PR0502MB3795.eurprd05.prod.outlook.com> <81f4bbef-8d6a-d845-eb07-966bbccf4849@intel.com> <AM6PR0502MB37974B11ADAC93B6419D957DC3670@AM6PR0502MB3797.eurprd05.prod.outlook.com> <ec715d6e-2db5-6645-485f-f0db93e2b058@intel.com> <AM6PR0502MB37979CF9A3EEF5D920AB9062C3620@AM6PR0502MB3797.eurprd05.prod.outlook.com> From: "Burakov, Anatoly" <anatoly.burakov@intel.com> 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: <AM6PR0502MB37979CF9A3EEF5D920AB9062C3620@AM6PR0502MB3797.eurprd05.prod.outlook.com> 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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=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