Thanks for the report. Order is with respect to packets that are on the origin queue, so if packets are dropped at the NIC and never received they shouldn't affect ordering. A stall should indicate that some thread is failing to resolve order, however any call to the scheduler implicitly resolves order for the prior context, so I'm not sure what might be going on from your description. Is there any way to obtain more information about the state of the system at the point of the hang?
>From gdb you can dump sched_local for each thread and that should contain relevant information about order state for each thread. On Thu, Jan 28, 2016 at 8:28 AM, Gábor Sándor Enyedi < [email protected]> wrote: > Hi, > > I may found a bug in ordered queues, but it seems to be so trivial that I > must think that I'm the one doing something wrong. The simplest way to > reproduce: > > Take odp_pktio, and change ODP_SCHED_SYNC_ATOMIC to > ODP_SCHED_SYNC_ORDERED. Now, start it using at least two threads and in > scheduled mode (-c 2 -m 2), and sometimes the traffic stops after some > hundred packets. Although, I was able reproduce the phenomenon with 2 > threads and 400mbps, the more threads and the higher bitrate gives you the > better chance to see it stopped. 12 threads and 30Gbps (40Gbps interface, > but pktgen can send only 30 with small packets) is almost always enough. > > Looking into the code with gdb, it seems that packets are received, but > queue_pktout_enq() puts the packets into a linked list (for reordering), > and it is waiting for the in-order packet which never arrives. I don't know > if that is lost, or was never received... I tried to set a breakpoint to > odp_packet_free() and to rte_pktmbuf_free(), but neither one was called. > Another interesting thing is that if packet forwarding starts successfully > (i.e. some thousand packets were forwarded), the traffic never stops. Is > this a bug, or just changing ODP_SCHED_SYNC_ATOMIC to > ODP_SCHED_SYNC_ORDERED is not enough, and something is missing? > Thanks, > > Gabor > _______________________________________________ > lng-odp mailing list > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
