odp_schedule_release_atomic() enables scheduling of other events from the same queue that was released but it doesn't relinquish the order requirement. Atomic scheduling implies ordered scheduling.
All of these things really need to be written down and agreed on. I think Petri has the strongest view on the desired semantics. On 15 October 2014 21:16, Bill Fischofer <[email protected]> wrote: > We need to be precise on semantics. Hopefully isn't a good term to use in > a spec. :) > > odp_schedule_release_atomic() means that the queue's atomicity guarantee > is deemed satisfied by the application at the point of the call. If the > application issued it prematurely, that's an application error, but if we > are expecting some other behavior on the part of the queue subsequent to > the call then we either have to expand on that or introduce some sort of > "Atomic Plus" queue that carries these additional semantics with it. > > On Wed, Oct 15, 2014 at 2:12 PM, Ola Liljedahl <[email protected]> > wrote: > >> For atomic queues, it makes sense to release the queue as quickly as >> possibly (e.g. when the queue context is no longer accessed) and allow the >> scheduler to schedule another packet from the same (atomic) queue to some >> other thread. The current thread could continue processing, doing some >> final updates to the packet or update non-context statistics, and then >> enqueue the packet. Hopefully ingress-egress ordering is still enforced >> when an atomic dispatch is released early. >> >> -- Ola >> >> >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
