The semantics of ordered queues still need to be fully (and rigorously) defined. Otherwise it's impossible to ensure that different implementations will yield the same results. Once we get past the "sunny day" tests, its the job of the test writer to be devious in trying to trick implementations into doing something that the spec says they shouldn't do. So Ciprian's scenario is a good one.
On Fri, Nov 21, 2014 at 11:30 AM, Taras Kondratiuk < [email protected]> wrote: > On 11/21/2014 06:16 PM, Ciprian Barbu wrote: > >> On Fri, Nov 21, 2014 at 5:54 PM, Bala Manoharan >> <[email protected]> wrote: >> >>> >>> Few points, >>> >>> * Inorder to check ordered state of buffers from second queue they >>> should be dequeued by a single thread >>> as scheduler will despatch the buffers from ORDERED queue in initial >>> order but more than one thread can get the buffer from the same queue at >>> the same time. >>> >> >> I was thinking something like this: q1 and q2 ORDERED queues. Buffers >> will first be pushed to the q1 to have something to work with. Then >> all buffers are dequeued and enqueued in q2 in, say, reverse order. >> Then the buffers are dequeued from q1 and the order should match the >> order in which they were pushed to q1. Did I get that right? >> > > That is actually more than you normally need from a scheduler. > Usually reordering happens because of packet processing parallelization on > several cores, but not because one core reorders packets. > > Petri, I don't remember if we discussed scenario described by Ciprian, > but previously you mentioned that ORDERED queues can be substituted by > ATOMIC if ORDERED are not supported by platform. But that won't work when > core reorders buffer intentionally. > > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
