On 21 April 2017 at 09:32, Bill Fischofer <bill.fischo...@linaro.org> wrote: > > > On Fri, Apr 21, 2017 at 1:27 AM, Bala Manoharan <bala.manoha...@linaro.org> > wrote: >> >> On 21 April 2017 at 02:05, Honnappa Nagarahalli >> <honnappa.nagaraha...@linaro.org> wrote: >> > On 20 April 2017 at 13:54, Bill Fischofer <bill.fischo...@linaro.org> >> > wrote: >> >> >> >> On Thu, Apr 20, 2017 at 12:26 PM, Honnappa Nagarahalli >> >> <honnappa.nagaraha...@linaro.org> wrote: >> >>> >> >>> Hi, >> >>> I looked at the shmem pool APIs for allocating smaller chunks of >> >>> shared memory. Following are the APIs I am looking at: >> >>> >> >>> odpdrv_shm_pool_create >> >>> odpdrv_shm_pool_destroy >> >>> odpdrv_shm_pool_alloc >> >>> odpdrv_shm_pool_free >> >>> >> >>> Few questions: >> >>> >> >>> 1) Why are these APIs prefixed with 'odpdrv', this should be 'odp'. >> >>> Are these APIs supposed to be used only by drivers? >> >> >> >> >> >> Christophe was using the prefix odpdrv_ for new "Southside" APIs. The >> >> idea >> >> is that the standard "Northside" (odp_ prefix) APIs are intended for >> >> use by >> >> applications to allow portability across different ODP implementations >> >> while >> >> the Southside APIs would provide the same sort of portability for >> >> drivers. >> >> These haven't been formalized (yet) so these are still under >> >> definition. I >> >> hope we'll be able to review / discuss these during the upcoming >> >> Sprint. >> >> >> >>> >> >>> 2) odpdrv_shm_pool_alloc - does not take 'alignment' input. The >> >>> scalable scheduler data structures need cache line alignment. >> >> >> >> >> >> These are prototypes at this point and if that's needed I'm sure it >> >> could >> >> easily be added. Since drivers are typically dealing with page-aligned >> >> ring >> >> buffers and such they would automatically be cache-aligned, so perhaps >> >> he >> >> didn't see the need to call that out explicitly. >> >> >> > >> > I find these APIs useful in allocating smaller chunks of shared memory >> > (may be some more functionality can be added to these APIs). I will >> > use them in the scalable scheduler for allocating shared memory for >> > queues. >> >> Since these are driver APIs they might not be available in all >> implementations. >> IMO, we need to keep scalable scheduler implementation independent >> from drv APIs. > > > Agree. Christophe developed his shm extensions with a view that they could > be used by both north and south APIs. That's the reason why _ishm.c exists. > Sounds like these should be made _ishm functions so that the scheduler can > use them as internal APIs. >
Most of the odpdrv_ APIs are wrappers around _odp_ishm_pool_xxx APIs (except for 1 API). I am able to use the internal APIs for now. I also think that these APIs need to be exposed to the application as well. Application will also have requirements to allocate shared memory. >> >> >> Regards, >> Bala >> > >> >>> >> >>> >> >>> Thanks, >> >>> Honnappa >> >> >> >> > >
