This is a non-trivial problem because it's not obvious what the "correct" answer is. While one can certainly engineer test cases where it's better to schedule completions back to the same core (e.g., cache is already "warm", etc.) that's not always the case. If at the time of completion the originating core has just started some other transaction but another core is free should you wait or go ahead and use the idle core? How about if there are now N events in the same situation?
In general it's poor design for the application to try to "outthink" the implementation on such things, just like you don't want to try to outthink the compiler when writing C code. That's essentially designing in an implementation model into the application, which is contrary to the performance and portability goals that ODP is trying to encourage. A better approach might be to have event attributes that are visible to the scheduler and then then let the implementations tune themselves to better take such considerations into account over time. Right now linux-generic, at least, has a very basic scheduler but you'd expect other implementations to have more sophisticated ones, especially as this model becomes more widespread. On Mon, May 4, 2015 at 9:57 AM, 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
