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. Regards, Bala > >>> >>> >>> Thanks, >>> Honnappa >> >>
