On 23 January 2017 at 13:45, Bill Fischofer <[email protected]> wrote: > 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? > One of the SoCs I had worked on provided WRR.
> 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? > I think we can say that the use case is WRR of scheduling (I am sure we can find actual use cases for which WRR was created). The number of events to be returned is dependent on the application's batch size. If there are 8 threads and each asking for 8 packets in a batch, depending on the queue depths, a thread might get 4 from high priority, 3 from medium and 1 from lower. If only high priority packets are available all 8 packets may come from high priority queue. > 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. > In the current implementation, re-ordering happens within the context of the queue (correct me if I am wrong). This requirement would require that re-ordering happen in the context of flow and queue (currently, I believe ODP treats both queue and flow the same). I think before we explore how complex it will be for a software implementation we should look at the use case/requirement. I believe, if NXP supports this capability in their SoC, it needs to be enabled in ODP in some fashion. > > 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 >> >>
