If I understand correctly, this is the scenario Ciprian described: Core : enqueue 1..n ----> q1 (ORDERED) ------> Core : dequeue 1..n, enqueue n..1 ------> q2 -----> Core : dequeue 1..n.
This scenario matches the definition of ORDERED queues, as proposed by Petri, regardless of what kind of queue is q2. Ordering should be restored even if q2 is a POLL queue, so in fact ordering is more a feature of enqueue rather than scheduler (dequeue). IMO this is a valid test of ORDERED queues (not ATOMIC). There is a main difference of how ordering is insured by the two queue types - ATOMIC preserves the order, ORDERED restores the order. Alex On 24 November 2014 at 07:34, Bala Manoharan <[email protected]> wrote: > Hi Ciprian, > > The scenario which you have described makes sense when a core dequeues > from an ORDERED queue and enqueues into an ATOMIC queue. I think we need to > properly describe the definition of ORDERED and ATOMIC queue before writing > TCs for the scenario you have defined. > > I would prefer to have only sunny day TC's for scheduler for the time > being. > > Regards, > Bala > > On 23 November 2014 07:25, Bill Fischofer <[email protected]> > wrote: > >> 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 > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
