Moving this discussion on the ODP mailing list rather than the Internal list as that way it will be archived.
The existing ODP controls over scheduling include schedule groups as well as queue priorities. The former is a strict requirement (threads can only receive events from queues that belong to a matching scheduler group). Queues can belong to only a single scheduler group that is set at odp_queue_create() time and is fixed for the life of the queue. Threads can belong to multiple scheduler groups and may change membership in these groups dynamically via the odp_schedule_group_join() and odp_schedule_group_leave() APIs. The latter (queue priority) is advisory. It is expected that in general threads will receive events originating on higher-priority queues ahead of those on lower-priority queues, but the default scheduler takes other factors into consideration to avoid starvation, etc. The "strict priority" (SP) scheduler makes priorities strict, so higher priority queues will always be scheduled ahead of lower priority queues even at the risk of starvation. What other scheduling controls are needed / desired? With regard to receiving events from multiple queues in response to odp_schedule_multi() there are several points that need clarification: 1. What is the use case for this capability? How many different events/queues would one expect to be eligible to be returned in a single call? Presumably this is a relatively small number (< 10). How does this compare with having multiple threads running in parallel servicing events from individual queues? 2. While semantically this would work for parallel queues, since the scheduler provides no synchronization context for events originating from parallel queues, is it acceptable / useful to have this restriction in the API? If not, then it's not obvious how multiple atomic or ordered contexts are expected to be maintained in any coherent fashion. This would seem to add significant complexity to any scheduler design, so we'd need a convincing use case to justify this. On Mon, Jan 23, 2017 at 11:05 AM, Nikhil Agarwal <[email protected]> wrote: > Adding internal mailing list.. > > On 23 January 2017 at 22:23, Honnappa Nagarahalli > <[email protected]> wrote: >> >> Hi Nikhil, >> I think it was a good discussion today on schedule_multi. I am >> also of the opinion that this API is really restrictive in terms of >> returning events from multiple queues in a single call. >> >> From today's call it looks to me that there is a lack of understanding >> of the use case for such as API. I think it will be useful to get a >> consensus on the use case as a first step and then talk about >> design/API. >> >> The current API seems to be designed with the thinking that the cores >> will always process only the highest priority packets, which is not >> correct. The fact that SoCs exist that support different scheduling >> algorithms and they are being used in deployment indicates the >> necessity of the new API. >> >> Thank you, >> Honnappa > >
