We can't talk about "atomicity" in a single thread context. I verified my implementation of ATOMIC queue this way - I modified odp_pktio to associate a POSIX binary semaphore initialized to 1 to each queue. When returning from odp_schedule() a thread does sem_trylock() on the queue semaphore and after enqueue to output queue does sem_post() if it locked the semaphore. For an atomic queue trylock should always succeed. Changing the queue sync to NONE there should be failures of trylock() for a certain rate injected into the device.
Alex On 24 November 2014 at 10:59, Ciprian Barbu <ciprian.ba...@linaro.org> wrote: > On Mon, Nov 24, 2014 at 9:47 AM, Alexandru Badicioiu > <alexandru.badici...@linaro.org> 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 <bala.manoha...@linaro.org> > > 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 <bill.fischo...@linaro.org> > >> 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 > >>> <taras.kondrat...@linaro.org> wrote: > >>>> > >>>> On 11/21/2014 06:16 PM, Ciprian Barbu wrote: > >>>>> > >>>>> On Fri, Nov 21, 2014 at 5:54 PM, Bala Manoharan > >>>>> <bala.manoha...@linaro.org> 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 > >>>> lng-odp@lists.linaro.org > >>>> http://lists.linaro.org/mailman/listinfo/lng-odp > >>> > >>> > >> > >> > >> _______________________________________________ > >> lng-odp mailing list > >> lng-odp@lists.linaro.org > >> http://lists.linaro.org/mailman/listinfo/lng-odp > >> > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
