On 12 April 2017 at 00:45, Bala Manoharan <[email protected]> wrote: > Regards, > Bala > > > On 12 April 2017 at 10:05, Honnappa Nagarahalli > <[email protected]> wrote: >> On 11 April 2017 at 05:51, Bala Manoharan <[email protected]> wrote: >>> On 10 April 2017 at 21:47, Honnappa Nagarahalli >>> <[email protected]> wrote: >>>> Hi Bala, >>>> Continuing the discussion from the call, as I mentioned in the >>>> call today, the queues need to hold all kinds of events and not just >>>> packets. The events need not be defined by ODP (like timeout events) >>>> also. The application may have its own events. >>>> >>>> In such a case, queue size does not dependent on the capacity of >>>> various pools supported in ODP. The size should depend on the >>>> implementation. >>> >>> ODP queues hold odp_event_t and these events needs to be allocated >>> from a pool even in case of a timer. >> >> If I create a queue between two pipeline stages, the producer can >> produce any 64b data and typecast it to odp_event_t and store it in >> the queue. The consumer can dequeue from that queue and use that 64b >> data according to the need of the application. It need not be >> allocated from any pool. > > The idea of storing it in the queue is the concern there are > implementations where queue is a virtual > concept and even in the use-case you have defined the data has to be > allocated from a memory region > and the pointer is only handled by the queue in my implementation. > so even if I return 0 for the capability it does not mean there is > unlimited possibility,
Agree. There is no true unlimited possibility. I am fine to change it to "Value of zero indicates the size is limited only by the available resources in the system at the time of creation." > there is a hidden limitation > either by the pool or by any memory region. In a software implementation of the pools, the size of the pool is again dependent on the available resources in the system. The size of the queue need not depend on the pool size. Application should decide how that dependency should be - it might want to configure the pool size depending on the queue size capability or vice versa. > >> >> Also since in your case you are returning >>> the maximum number of events across all the queues there needs to be a valid >>> use-case for this value. >> >> The capability API would return the maximum size of a queue that the >> application can create - if there is a fixed maximum queue size. >> Otherwise, it would return 0, indicating that the max size is not >> fixed - it is dependent on available resources at the time of >> creation. One could create 10 queues of size 1K elements, but there >> are not enough resources to create 11th queue with a size of 1K at >> that point in time. >> >>> >>> Regards, >>> Bala >>> >>>> >>>> If the queue is allocated out of memory, then the size should depend >>>> on the available amount of memory at any point in time. >>>> >>>> Thank you, >>>> Honnappa >>>> >>>> On 7 April 2017 at 02:54, Savolainen, Petri (Nokia - FI/Espoo) >>>> <[email protected]> wrote: >>>>> See my patch series: [PATCH v3 1/2] api: queue: added queue size param >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: lng-odp [mailto:[email protected]] On Behalf Of >>>>>> Honnappa Nagarahalli >>>>>> Sent: Friday, April 07, 2017 7:07 AM >>>>>> To: [email protected] >>>>>> Subject: [lng-odp] [PATCH 1/2] add queue size param and related >>>>>> capability >>>>>> >>>>>> Added size parameter indicating the maximum number of events in the >>>>>> queue and the corresponding queue capability changes. >>>>>> >>>>>> Signed-off-by: Honnappa Nagarahalli <[email protected]> >>>>>> --- >>>>>> include/odp/api/spec/queue.h | 12 ++++++++++++ >>>>>> platform/linux-generic/odp_queue.c | 1 + >>>>>> 2 files changed, 13 insertions(+) >>>>>> >>>>>> diff --git a/include/odp/api/spec/queue.h b/include/odp/api/spec/queue.h >>>>>> index 7972fea..ccb6fb8 100644 >>>>>> --- a/include/odp/api/spec/queue.h >>>>>> +++ b/include/odp/api/spec/queue.h >>>>>> @@ -112,6 +112,12 @@ typedef struct odp_queue_capability_t { >>>>>> /** Number of scheduling priorities */ >>>>>> unsigned sched_prios; >>>>>> >>>>>> + /** Maximum number of events in the queue. >>>>>> + * >>>>>> + * Value of zero indicates the size is limited only by the >>>>>> available >>>>>> + * memory in the system. */ >>>>>> + unsigned max_size; >>>>>> + >>>>>> } odp_queue_capability_t; >>>>>> >>>>>> /** >>>>>> @@ -124,6 +130,12 @@ typedef struct odp_queue_param_t { >>>>>> * the queue type. */ >>>>>> odp_queue_type_t type; >>>>>> >>>>>> + /** Queue size >>>>>> + * >>>>>> + * Maximum number of events in the queue. Value of 0 chooses >>>>>> the >>>>>> + * default configuration of the implementation. */ >>>>>> + uint32_t size; >>>>>> + >>>>>> /** Enqueue mode >>>>>> * >>>>>> * Default value for both queue types is ODP_QUEUE_OP_MT. >>>>>> Application >>>>>> diff --git a/platform/linux-generic/odp_queue.c b/platform/linux- >>>>>> generic/odp_queue.c >>>>>> index fcf4bf5..5a50a57 100644 >>>>>> --- a/platform/linux-generic/odp_queue.c >>>>>> +++ b/platform/linux-generic/odp_queue.c >>>>>> @@ -175,6 +175,7 @@ int odp_queue_capability(odp_queue_capability_t >>>>>> *capa) >>>>>> capa->max_ordered_locks = sched_fn->max_ordered_locks(); >>>>>> capa->max_sched_groups = sched_fn->num_grps(); >>>>>> capa->sched_prios = odp_schedule_num_prio(); >>>>>> + capa->max_size = 0; >>>>>> >>>>>> return 0; >>>>>> } >>>>>> -- >>>>>> 2.7.4 >>>>>
