From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) by dpdk.org (Postfix) with ESMTP id 6F0E74CE6 for ; Fri, 22 Jul 2016 11:14:56 +0200 (CEST) Received: by mail-lf0-f53.google.com with SMTP id l69so81157411lfg.1 for ; Fri, 22 Jul 2016 02:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=cTLvks7HDdMSkbw+WqoHiUXUHeBGtuDOQGtO0DWvx+s=; b=RXsVQhmlIFKWgTLMhM/BWxOLp2LGMKT5oFgb410XsmxpytvUmwFCFWPu24sFokUorX WXENfBmghDhTrz5F3Qw9a0vt9Lz4ViIqFvkV/0qh36KD+hGfrwR0d52gW1OrWmQPyj7G fCCYGqlpVJS+z2t15dD7s0o7MfBCscfOSgG3036m5O5HC4OfOdb/w81Tx5veth3wFhuy wiTlFk9XUt3g1NetrGbM3mVocaLZ41/dvf5IcLj55oUq5XbtZW4lndUHV8d+IjKYgBrh K2tgm6t8S1WLYxbN65yMv3emKKap2ZJl4H/NWdUAUj3mlxV6Nu+PTqjw1ddvxw1lj1q1 HVug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=cTLvks7HDdMSkbw+WqoHiUXUHeBGtuDOQGtO0DWvx+s=; b=iGenDmcv1azSFF9gnWX4InfBRKlTr5KukBNH9avrefKYysjotkWIKPskKBfSFIuvvG Y464pS9ggEWdJhf+MHzg4lmN2lRmZ7MplrMWeKkGl54sQh+e86fJq+ncNqoSmbB1Dx8b eeiJCYl54GAGCVmeEjw9J4tfX1EQJaosdvJlrEZuiDot2ewAZO7rx62PCftsxN8lMI0w yVP8A6y7rF4KhnKYbmFRLnVbBS3Ht4drJMEFC2rs3iJQCM0NRofQ4q8JrtuPX+Kx2aud dlSgeklDOAeYGJc6rJmYmmSIisSzXNtD/mqRACmkSWlzdzAfuNM3u5snot+BawK+qjWU Clyg== X-Gm-Message-State: AEkoouuOACbj6zP/96kGc1WFhaAK70F/mLzNmMHmF5pehVWL8FWbfx9qKxEP1eaffSk1Uh6PrBP5Z9E/e4hsZQ== X-Received: by 10.46.71.17 with SMTP id u17mr2173006lja.49.1469178895993; Fri, 22 Jul 2016 02:14:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.68.162 with HTTP; Fri, 22 Jul 2016 02:14:54 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?0KHQtdGA0LPQtdC5INCb0YzQstC+0LI=?= Date: Fri, 22 Jul 2016 12:14:54 +0300 Message-ID: To: users@dpdk.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] Fwd: possible rte_ring issues: retransmission X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2016 09:14:56 -0000 ---------- Forwarded message ---------- From: CIDJEY Date: 2016-07-22 12:13 GMT+03:00 Subject: Fwd: possible rte_ring issues: retransmission To: =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B9 =D0=9B=D1=8C=D0=B2=D0=BE=D0=B2 ---------- Forwarded message ---------- From: CIDJEY 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 =3D=3D 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