From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH 20/20] bus/fslmc: add function to map any addr via VFIO Date: Fri, 11 Jan 2019 11:58:55 +0000 Message-ID: References: <20181227062233.30781-1-hemant.agrawal@nxp.com> <20181227062233.30781-21-hemant.agrawal@nxp.com> <644680ea-c4f7-3295-feef-47475d870596@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Pankaj Chauhan , "M.h. Lian" To: Shreyansh Jain , Hemant Agrawal , "dev@dpdk.org" Return-path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id A5DF11BBDA for ; Fri, 11 Jan 2019 12:58:58 +0100 (CET) In-Reply-To: <644680ea-c4f7-3295-feef-47475d870596@nxp.com> Content-Language: en-US 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 1/10/2019 9:58 AM, Shreyansh Jain wrote: > Hello Ferruh, > > Replying on behalf of Hemant... > > On 08/01/19 7:40 PM, Ferruh Yigit wrote: >> On 12/27/2018 6:23 AM, Hemant Agrawal wrote: >>> From: Pankaj Chauhan >>> >>> This is required to map any accelerator memory >>> and PCI address to VFIO using QDMA. >>> >>> Signed-off-by: Minghuan Lian >>> Signed-off-by: Pankaj Chauhan >> >> This requires either sign-off or ack from 'bus/fslmc' maintainers, which are: >> M: Hemant Agrawal >> >> >> >> M: Shreyansh Jain >> >> I think Hemant sending the patchset implies that this has been reviewed by him >> but this information get lost in git, so better to explicitly provide review/ack >> tags whenever appropriate. > > What I will do is, re-spin the complete series (with error below > fixed...) and send again. All the patches are on FSLMC/DPAA2 drivers > only so probably Hemant's or my Acks would work directly. > >> >> <...> >> >>> + printf("PCIe vfio map 0x%llx:0x%llx, size 0x%llx\n", dma_map.vaddr, >>> + dma_map.iova, dma_map.size); >> >> This is causing build error [1], but why at first place using 'printf()' instead >> of logging macros? > > I will fix this. > >> >> [1] >> .../drivers/bus/fslmc/fslmc_vfio.c: In function ‘rte_fslmc_vfio_mem_dmamap’: >> .../drivers/bus/fslmc/fslmc_vfio.c:376:29: error: format ‘%llx’ expects argument >> of type ‘long long unsigned int’, but argument 2 has type ‘__u64’ {aka ‘long >> unsigned int’} [-Werror=format=] >> printf("PCIe vfio map 0x%llx:0x%llx, size 0x%llx\n", dma_map.vaddr, >> ~~~^ ~~~~~~~~~~~~~ >> %lx >> >> <...> >> >>> +DPDK_19.02 { >>> + global: >>> + >>> + rte_fslmc_vfio_mem_dmamap; >> >> Is this need to be an API? Who is the consumer of this API, I don't see anyone >> calls this function? >> > > This API (internal to FSLMC) was added for one of NXP's internal > software stack over DPDK. As this is an internal API, I don't think it > would pollute the outer namespace - isn't it? And, I think its consumers > won't necessarily be within DPDK stack. > > Or, if this is conflicting case, I will remove this patch (it is > independent) and send again. Let me know your reservation. API consumers doesn't have to be in DPDK but than it is not an internal API. And for API we recently decided to have an implementation for new APIs, it can be unit test, sample application, or app like testpmd, so that we can detect when it is broken. Perhaps it can be good idea to separate patch, as you suggested, to not block the rest of the patchset.