Thread (70 messages) 70 messages, 3 authors, 2019-01-14

Re: [PATCH 20/20] bus/fslmc: add function to map any addr via VFIO

From: Shreyansh Jain <hidden>
Date: 2019-01-10 09:58:27

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:
quoted
From: Pankaj Chauhan <redacted>

This is required to map any accelerator memory
and PCI address to VFIO using QDMA.

Signed-off-by: Minghuan Lian <Minghuan.Lian@nxp.com>
Signed-off-by: Pankaj Chauhan <redacted>
This requires either sign-off or ack from 'bus/fslmc' maintainers, which are:
	M: Hemant Agrawal [off-list ref]



	M: Shreyansh Jain [off-list ref]

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.
<...>
quoted
+	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

<...>
quoted
+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.

-
Shreyansh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help