On Tue, Apr 11, 2017 at 11:14 PM, Honnappa Nagarahalli <[email protected]> wrote: > 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.
Back pressure is normally an implementation area because it is a feature of hardware. If we expect applications to use platform-specific features to implement this themselves, then this defeats the portability goal of ODP. If the implementation doesn't use back pressure, then odp_queue_enq() will fail when a queue is full and applications can take whatever recovery action is appropriate, same as the would on an allocation failure. > >> >>> >>> 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 >>>>
