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
