Re: [lng-odp] shmem pool APIs

[Honnappa Nagarahalli]

On 21 April 2017 at 09:32, Bill Fischofer  wrote:
>
>
> On Fri, Apr 21, 2017 at 1:27 AM, Bala Manoharan 
> wrote:
>>
>> On 21 April 2017 at 02:05, Honnappa Nagarahalli
>>  wrote:
>> > On 20 April 2017 at 13:54, Bill Fischofer 
>> > wrote:
>> >>
>> >> On Thu, Apr 20, 2017 at 12:26 PM, Honnappa Nagarahalli
>> >>  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
>> >>
>> >>
>
>

Re: [lng-odp] shmem pool APIs

[Bill Fischofer]

On Fri, Apr 21, 2017 at 1:27 AM, Bala Manoharan 
wrote:

> On 21 April 2017 at 02:05, Honnappa Nagarahalli
>  wrote:
> > On 20 April 2017 at 13:54, Bill Fischofer 
> wrote:
> >>
> >> On Thu, Apr 20, 2017 at 12:26 PM, Honnappa Nagarahalli
> >>  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.


>
> Regards,
> Bala
> >
> >>>
> >>>
> >>> Thanks,
> >>> Honnappa
> >>
> >>
>

Re: [lng-odp] shmem pool APIs

[Bala Manoharan]

On 21 April 2017 at 02:05, Honnappa Nagarahalli
 wrote:
> On 20 April 2017 at 13:54, Bill Fischofer  wrote:
>>
>> On Thu, Apr 20, 2017 at 12:26 PM, Honnappa Nagarahalli
>>  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
>>
>>

Re: [lng-odp] shmem pool APIs

[Maxim Uvarov]

On 04/20/17 21:54, Bill Fischofer 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.
> 
>

idea is that you should compile odp driver without odp.

>>
>> Thanks,
>> Honnappa
>>

Re: [lng-odp] shmem pool APIs

[Bill Fischofer]

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.


>
> Thanks,
> Honnappa
>