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? Just as app need to allocate memory differently, app creates the pool on its own memory and app uses the pool. > > 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.). So these things is done by ODP shm as before. This adding of pool param doesn't change anything before. After this adding, App can uses it own pool on its own memory. Regards, Zaibo 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
