On 01/14/2016 04:28, Xu Zaibo wrote:
Hi,
Firstly, I don't want to bring any new type of pool into ODP.
I just want to give user more chance to use more areas of memory. For example,
referring to your example of various HW offload engines, if there two or more
types of engines
which have different request on memory attributions exist in the same system,
which means that one odp_shm_reserve function cannot cover the attributions.
What should we do?
In that case odp application developer should not care about any
internal memory allocation resources and its. I.e. app has to be portable.
How it will be portable if each app will allocate memory differently?
Moreover, ODP's odp_shm_reserve function cannot cover all kinds requests of
users, even if we use the parameter of flags to define different kind of memory
in the fucntion of odp_shm_reserve
in my opinion. And user gives its own reserve function, which should be keep
safe by user. For example, user have to make sure engines can access the
packets from its own memory.
What is use case?
app does not know about underlying system anything, about memory layout,
numa nodes and etc. Implementation knows about hardware everything. All
of that should be internal (i.e. inside implementation.).
Regards,
Maxim.
So let's try to give user chance. Thanks.
Have a good day
Zaibu Xu
-----邮件原件-----
发件人: Savolainen, Petri (Nokia - FI/Espoo) [mailto:petri.savolai...@nokia.com]
发送时间: 2016年1月13日 17:49
收件人: Xu Zaibo; Tangchaofei; Liuzhongzhu; chenlizhi; yangfajun; Huwei (Xavier)
抄送: lng-odp@lists.linaro.org
主题: RE: [lng-odp] [PATCH] pool:support to create pool on user's own memory
Hi,
What object types you'd allocate from the pool? Packets, buffers, timeouts or
some other application specific object?
If it's application specific objects, we'd actually need to define a new pool
type which can store references to any object type (e.g. uintptr_t). You could
store pointers to memory blocks, table indexes, etc - basically anything.
This modification seems to expect that any implementation can form any type of
pool from any address the user callback function returns to it. Linux-generic
could do that (if memory is shared), but it would be troublesome to other
implementations. For example, various HW offload engines (queues, scheduler,
crypto, pktin, pktout, tm) must be able to access packets.
-Petri
-----Original Message-----
From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of
EXT Zaibo Xu
Sent: Tuesday, January 12, 2016 9:23 AM
To: tangchao...@huawei.com; liuzhong...@huawei.com;
chenli...@huawei.com; yangfa...@huawei.com; xavier.hu...@huawei.com;
xuza...@huawei.com
Cc: lng-odp@lists.linaro.org
Subject: [lng-odp] [PATCH] pool:support to create pool on user's own
memory
As user initiates pool params with its own memory reserving and un-
reserving functions, pool will be created on its own memory, or on odp
share memory as before.
Signed-off-by: Zaibo Xu <xuza...@huawei.com>
---
include/odp/api/pool.h | 12 ++++++++++++
platform/linux-generic/odp_pool.c | 34
+++++++++++++++++++++++++---------
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/include/odp/api/pool.h b/include/odp/api/pool.h index
2e79a55..fce0592 100644
--- a/include/odp/api/pool.h
+++ b/include/odp/api/pool.h
@@ -40,6 +40,12 @@ extern "C" {
/** Maximum queue name length in chars */ #define ODP_POOL_NAME_LEN
32
+/** For user's memory reserve function */ typedef void*
+(*odp_usr_resv_mem_t)(uint32_t len);
+
+/** For user's memory un-reserve function */ typedef int
+(*odp_usr_unresv_mem_t)(void *addr);
+
/**
* Pool parameters
* Used to communicate pool creation options.
@@ -48,6 +54,12 @@ typedef struct odp_pool_param_t {
/** Pool type */
int type;
+ /** Odp pool can be created on user's own memory.
+ there are memory reserve and un-reserve
+ functions of user. */
+ odp_usr_resv_mem_t resv_mem_fn;
+ odp_usr_unresv_mem_t unresv_mem_fn;
+
union {
struct {
/** Number of buffers in the pool */ diff --git
a/platform/linux-generic/odp_pool.c b/platform/linux-
generic/odp_pool.c index 84d35bf..eb8b153 100644
--- a/platform/linux-generic/odp_pool.c
+++ b/platform/linux-generic/odp_pool.c
@@ -295,15 +295,27 @@ odp_pool_t odp_pool_create(const char *name,
odp_pool_param_t *params)
mdata_size +
udata_size);
- shm = odp_shm_reserve(pool->s.name,
- pool->s.pool_size,
- ODP_PAGE_SIZE, 0);
- if (shm == ODP_SHM_INVALID) {
- POOL_UNLOCK(&pool->s.lock);
- return ODP_POOL_INVALID;
+ if (pool->s.params.resv_mem_fn != NULL) {
+ void *addr = pool->s.params.resv_mem_fn(
+ (uint32_t)pool->s.pool_size);
+
+ if (addr == NULL) {
+ POOL_UNLOCK(&pool->s.lock);
+ return ODP_POOL_INVALID;
+ }
+ pool->s.pool_base_addr = (uint8_t *)addr;
+ pool->s.pool_shm = (odp_shm_t)!ODP_SHM_INVALID;
+ } else {
+ shm = odp_shm_reserve(pool->s.name,
+ pool->s.pool_size,
+ ODP_PAGE_SIZE, 0);
+ if (shm == ODP_SHM_INVALID) {
+ POOL_UNLOCK(&pool->s.lock);
+ return ODP_POOL_INVALID;
+ }
+ pool->s.pool_base_addr = odp_shm_addr(shm);
+ pool->s.pool_shm = shm;
}
- pool->s.pool_base_addr = odp_shm_addr(shm);
- pool->s.pool_shm = shm;
/* Now safe to unlock since pool entry has been allocated */
POOL_UNLOCK(&pool->s.lock);
@@ -473,7 +485,11 @@ int odp_pool_destroy(odp_pool_t pool_hdl)
return -1;
}
- odp_shm_free(pool->s.pool_shm);
+ if (pool->s.params.unresv_mem_fn != NULL)
+ pool->s.params.unresv_mem_fn((void *)pool->s.pool_base_addr);
+ else
+ odp_shm_free(pool->s.pool_shm);
+
pool->s.pool_shm = ODP_SHM_INVALID;
POOL_UNLOCK(&pool->s.lock);
--
1.9.1
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/lng-odp
