Thread (128 messages) 128 messages, 11 authors, 2021-11-08

Re: [dpdk-dev] [PATCH] gpudev: introduce memory API

From: Wang, Haiyue <hidden>
Date: 2021-06-04 18:04:57

-----Original Message-----
From: Thomas Monjalon <redacted>
Sent: Friday, June 4, 2021 22:06
To: Wang, Haiyue <redacted>
Cc: dev@dpdk.org; Elena Agostini <redacted>; andrew.rybchenko@oktetlabs.ru; Yigit, Ferruh
[off-list ref]; jerinj@marvell.com
Subject: Re: [dpdk-dev] [PATCH] gpudev: introduce memory API

04/06/2021 15:25, Wang, Haiyue:
quoted
From: Thomas Monjalon <redacted>
quoted
Another question is about the function rte_gpu_free().
How do we recognize that a memory chunk is from the CPU and GPU visible,
or just from GPU?
I didn't find the rte_gpu_free_visible definition, and the rte_gpu_free's
comment just says: deallocate a chunk of memory allocated with rte_gpu_malloc*

Looks like the rte_gpu_free can handle this case ?
This is the proposal, yes.
quoted
And from the definition "rte_gpu_free(uint16_t gpu_id, void *ptr)", the
free needs to check whether this memory belong to the GPU or not, so it
also can recognize the memory type, I think.
Yes that's the idea behind having a single free function.
We could have some metadata in front of the memory chunk.
My question is to confirm whether it is a good design or not,
and whether it should be driver specific or have a common struct in the lib.

Opinions?
Make the GPU memory to be registered into the common lib API with the metadata
like address, size etc, and also some GPU specific callbacks like to handle how
to make GPU memory visible to CPU ?

And the memory register can be like the exist external memory function:

int
rte_extmem_register(void *va_addr, size_t len, rte_iova_t iova_addrs[],
		unsigned int n_pages, size_t page_sz)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help