On Mon, Nov 24, 2014 at 9:47 AM, Alexandru Badicioiu <[email protected]> wrote: > 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.
Yeah, this was my understanding of ORDERED queues as well. We need to talk more about this, but if this is not the definition of ORDERED queues as we need to agree on for v1.0 then I need to properly understand how to do a "sunnyday" test for restoring the order. Simply queuing packets in the same order by a single thread matches the definition for ATOMIC, right? /Ciprian > > 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 > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
