This is on API todo list with high priority. We'll actually change from cpu IDs to thread IDs while adding this mapping. So, application lists (per queue) a set of thread IDs (into schedule group) that are available for the scheduler to choose from. The default is "all" threads.
-Petri > -----Original Message----- > From: lng-odp [mailto:[email protected]] On Behalf Of ext > Jacob, Jerin > Sent: Tuesday, May 05, 2015 9:28 AM > To: Alexandru Badicioiu; Ciprian Barbu > Cc: lng-odp > Subject: Re: [lng-odp] Queue cpumask for IPSEC scenario > > > But the mapping between odp_schedule_group_t to odp_cpumask_t for the > cpu's allowed to schedule is missing in the current spec. > > /Jerin > > > From: lng-odp <[email protected]> on behalf of Alexandru > Badicioiu <[email protected]> > Sent: Tuesday, May 5, 2015 11:47 AM > To: Ciprian Barbu > Cc: lng-odp > Subject: Re: [lng-odp] Queue cpumask for IPSEC scenario > > > Queue sched group is meant to specify which cores will receive events from > that queue. You would create the completion queue in a scheduler group > containing the target core. > > > Hope this helps, > Alex > > > On 4 May 2015 at 17:57, Ciprian Barbu <[email protected]> wrote: > Hi, > > I received this question internally from some people looking at ODP, I > don't know how to answer. It goes like this. > > Say you want to execute a crypto session in async mode, using a > completion queue. A core would initiate the session and the go about > it's business. ODP will execute the operation in async mode and push > the completion event in the specified queue when ready. Now, the > application must either wait in a loop trying to receive from that > queue or to use odp_schedule for a more general programming model, > where it always calls odp_schedule. > > The question is, isn't there a way to make sure the completion event > will be received by the core that initiated the operation and not some > random one depending on how the scheduler will treat the event? I > remember something about cpumask for queues, but we have abandoned > that concept. > > /Ciprian > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
