> -----Original Message----- > From: ext Maxim Uvarov [mailto:maxim.uva...@linaro.org] > Sent: Wednesday, October 22, 2014 4:41 PM > To: Savolainen, Petri (NSN - FI/Espoo); Jerin Jacob > Cc: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] [PATCH] ipc linux-generic implementation based on > pktio > > On 10/22/2014 05:14 PM, Savolainen, Petri (NSN - FI/Espoo) wrote: > >> I think it might be better to add extend odp_buffer_pool_create: > >> > >> odp_buffer_pool_t odp_buffer_pool_create(const char *name, > >> void *base_addr, uint64_t > size, > >> size_t buf_size, size_t > >> buf_align, > >> int buf_type) > >> > >> provide base_addr as remote_pool_mapped_base address and buf_type as: > >> ODP_BUFFER_TYPE_IPC > >> > >> In that case I will not allocate memory, will link pktio with remote > >> base_addr. > >> Will check how is it implementable. > >> > >> Will send new version of patch. > >> > >> Maxim. > > After my latest shm changes (reference shm with handle), I was going > change buffer pool create to use that handle. It should be done still, and > after that pool create can see e.g. the shm flags. No need to " > remote_pool_mapped_base address", right? > > > > odp_buffer_pool_t odp_buffer_pool_create(const char *name, > > odp_shm_t shm, > > size_t buf_size, size_t > buf_align, int buf_type) > > > > -Petri > > > Yes, in that case it will solve that problem. But after that we will > lost ability to app allocate memory for pool. Do we need both handler > and pointer? Or do we need to allocate memory for pool from application > for any reason? > > Maxim. > >
This would be the version where application gives the memory. More commonly application could leave shm invalid and let the implementation reserve the memory for the pool. It's safer that the memory range is under implementation control. -Petri _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
