Hi, So, it is sure that implementation may need different kinds of memory.
After adding user's own memory operations to the pool param, all the functions of odp_pool_create before are not changed. An implementation is still asking memory from ODP shm or some other internal memory as before. I don’t understand that why implementation will ask memory from application, as ODP has memory pools and implementation should know when and where to create what kind of pool. Finally, implementation can have kinds of memory, user also has kinds of memory and user may intend to create the ODP pool on its own kind of memory to adapt its module to other modules of ODP. User creates its own pool, after using, destroys it. Meanwhile, implementation creates pool, uses pool and destroys it. No matter adding user's own memory operations to the pool param or not, the guy using a pool should know what is the pool using for and what is the pool's attributions. Zaibo Xu -----邮件原件----- 发件人: Savolainen, Petri (Nokia - FI/Espoo) [mailto:petri.savolai...@nokia.com] 发送时间: 2016年1月14日 23:00 收件人: 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, So, it would be memory for any pool type. If an implementation asks memory from the application, portability becomes a problem. How application would know which kind of memory each implementation would need for each pool type? Linux-generic uses ODP shm to reserve memory for pools, but some implementation would prefer to use e.g. SoC internal memory (SRAM, instead of DRAM) for packet pools that are small enough to fit there. This was one of the reasons we removed shm from pool parameters earlier (application don't create and pass memory for pools, but implementation does it by itself). So, the question is how application could tell implementation to prefer memory X for one pool and memory Y for another pool. Are there generic parameters that could describe properties of these two memories. -Petri > -----Original Message----- > From: EXT Xu Zaibo [mailto:xuza...@huawei.com] > Sent: Thursday, January 14, 2016 3:28 AM > To: Savolainen, Petri (Nokia - FI/Espoo); Tangchaofei; Liuzhongzhu; > chenlizhi; yangfajun; Huwei (Xavier) > Cc: lng-odp@lists.linaro.org > Subject: 答复: [lng-odp] [PATCH] pool:support to create pool on user's > own memory > > 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? > > 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. > > 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
