[dpdk-users] Fwd: possible rte_ring issues: retransmission

[dpdk-users] Fwd: possible rte_ring issues: retransmission

[Сергей Львов]

---------- Forwarded message ----------
From: CIDJEY <ciddjey@gmail.com>
Date: 2016-07-22 12:13 GMT+03:00
Subject: Fwd: possible rte_ring issues: retransmission
To: Сергей Львов <log0div0@gmail.com>



---------- Forwarded message ----------
From: CIDJEY <ciddjey@gmail.com>
Date: 2016-07-22 13:04 GMT+04:00
Subject: possible rte_ring issues: retransmission
To: users@dpdk.org


I'm sorry guys, I had to retransmit this message: my other mail domain
seems to be caught in the gmail spam filter, so I assumed all the guys
with gmail didn't see the message as well. Sorry if you see this
message twice.


Hi guys

I have a pipeline-like application - 3 modules (rx, worker, tx)
connected by rings.

Rx module gets the packtes, timestamps them and then sends them to the
worker via a ring. The ring has single producer (rx) and single
consumer (worker).
I've noticed that sometimes the worker gets some packets with
inconsistent timestamps: the timestamp of the next incoming packets is
less then the timestamp of the previous packet. Usually after that
follows another 2 or 3 packets with inconsistent timestamps. Then
everything get fine for some time. It happens quite often: every
10000-2000 packets.

I've put a check function for following timestamps on the outgress and
ingress points of each module. It seems that on the outgress point of
the RX module (before the  rte_ring_enqueue_bulk  into the ring) the
timestamps are totally fine, but on the ingress point of the worker
(after rte_ring_dequeue_burst from the ring) some packets come in the
wrong order. It happens only between the bursts, the packets within
one burst are always consistent.

For example: the RX sent 20 packets in a bulk, the worker then
recieves 10 packets in one burst and 10 in another.
So sometimes I can see, that the first burst consists of the packets
1-2-3-4-5-6-7-8-11-12 and the second consists of the packets
9-10-13-14-15-16-17-18-19-20.
(Then again - on the out point of RX everything was perfectly fine)

And that wouldn't be that much of an issue, but my worker module is
highly sensitive to this sort of things. It totally breaks its logic.

Is that how the ring behaviour supposed to be? Am I missing something?
 Is there a way to force rings to deliver packets in the order they
were sent?

I'm using DPDK 2.2.0

Thanks in advance.


*Update:*

A little update, I hope it will clarify things a bit.
I've replaced timestamp checking with the counters, so here's the
actual example:

Before another burst the worker expects to get packet 410. Instead it
gets the burst of the next 6 packets: 412-413-414-415-416-417. The
counters on the RX tell me, that RX already sent 417 packets. So the
worker now misses two packets: 410-411. By the way, in the ring by
this exactly moment (if we can trust gdb) prod.tail == cons.tail, so
it seems there're no packets in the ring. It seems the 2 packets have
been just plain lost.

But after that if we proceed to the next dequeue_burst (also with the
gdb) we get another 32 packets, and the first two of them are the
missing 410-411. Oddly enough, after those two follow 450-451 and so
on, and on the NEXT dequeue burst we get another 32 packets: 418-449
(basically the ones that should be instead of the previous 32
packets)... I'm confused.

What is going on? Is it normal? How may I make sure the packets are
transferred in the right order?

Thanks