On 10 April 2017 at 11:49, Bill Fischofer <[email protected]> wrote: > On Mon, Apr 10, 2017 at 11:17 AM, 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. >> >> 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.
I prefer to leave the back pressure implementation to the application. This allows the application to have different algorithms to wait till the queue has space. For ex: on ARM platforms, the implementation can use WFE/SEV. > >> >> 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 >>>
