On Mon, Apr 10, 2017 at 11:17 AM, Honnappa Nagarahalli <honnappa.nagaraha...@linaro.org> 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. > > If the queue is allocated out of memory, then the size should depend > on the available amount of memory at any point in time.
The real distinction is whether the implementation imposes a fixed upper bound to queue size. This may be, for example, because queues are implemented in hardware and there are hardware-imposed limits to queue size. Or it may be that the implementation preallocates resources at configuration time and these have fixed numbers associated with them. ODP got along just fine before without having known queue sizes, so the question is "what new information does the application want here"? The only use-case we seem to have identified is the application intends to use a queue as a storage mechanism and it wants to ensure that the queue has a minimum storage capacity at queue create time. In this case, the capability is reporting whether there is a fixed upper bound that the application can use to compare to its minimum requirements. If the answer is "yes", then the application can adjust its needs (or refuse to run) based on that answer. If the answer is "no" (a returned 0 as max_size) then the application can specify it's requested size as input to odp_queue_create() and observe whether the request succeeds or fails. The alternative is to not add a max_size to odp_queue_capability() at all and simply let odp_queue_create() report success or failure in response to a requested size. That's effectively what we have today, except that by default the requested "size" is forced to 0, meaning that the implementation chooses what, if any, such limits exist. The only way these limits are surfaced to applications is if odp_queue_enq() fails because the queue is full and the implementation doesn't use back pressure. If back pressure is used, then the odp_queue_enq() call simply stalls until room is made available in the queue to satisfy the request. > > Thank you, > Honnappa > > On 7 April 2017 at 02:54, Savolainen, Petri (Nokia - FI/Espoo) > <petri.savolai...@nokia-bell-labs.com> wrote: >> See my patch series: [PATCH v3 1/2] api: queue: added queue size param >> >> >>> -----Original Message----- >>> From: lng-odp [mailto:lng-odp-boun...@lists.linaro.org] On Behalf Of >>> Honnappa Nagarahalli >>> Sent: Friday, April 07, 2017 7:07 AM >>> To: lng-odp@lists.linaro.org >>> 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 <honnappa.nagaraha...@linaro.org> >>> --- >>> 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 >>
