Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter

[Alexander Belyakov <abelyako@gmail.com>]

Hello,


On Sat, Nov 2, 2013 at 9:29 AM, Prashant Upadhyaya <
prashant.upadhyaya@aricent.com> wrote:

> Hi Alexander,
>
> Regarding your following statement --
> "
> The only drop counter quickly increasing in the case of pure ACK flood is
> ierrors, while rx_nombuf remains zero.
> "
>
> Can you please explain the significance of "ierrors" counter since I am
> not familiar with that.
>
>
I was speaking about struct rte_eth_stats fields.
http://dpdk.org/doc/api/structrte__eth__stats.html


> Further,  you said you have 4 queues, how many cores  are you using for
> polling the queues ? Hopefully 4 cores for one queue each without locks.
> [It is absolutely critical that all 4 queues be polled]
>

There were one independent core per each RX queue, of course.

Further, is it possible so that your application itself reports the traffic
> receive in packets per second on each queue ? [Don't try to forward the
> traffic here, simply receive and drop in your app and sample the counters
> every second]
>

 There are DPDK counters for RX packets per queue in the same struct
rte_eth_stats. TX was not an issue in this case.


>
> Regards
> -Prashant
>
>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Alexander Belyakov
> Sent: Friday, November 01, 2013 7:13 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] Surprisingly high TCP ACK packets drop counter
>
> Hello,
>
> we have simple test application on top of DPDK which sole purpose is to
> forward as much packets as possible. Generally we easily achieve 14.5Mpps
> with two 82599EB (one as input and one as output). The only suprising
> exception is forwarding pure TCP ACK flood when performace always drops to
> approximately 7Mpps.
>
> For simplicity consider two different types of traffic:
> 1) TCP SYN flood is forwarded at 14.5Mpps rate,
> 2) pure TCP ACK flood is forwarded only at 7Mpps rate.
>
> Both SYN and ACK packets have exactly the same length.
>
> It is worth to mention, this forwarding application looks at Ethernet and
> IP headers, but never deals with L4 headers.
>
> We tracked down issue to RX circuit. To be specific, there are 4 RX queues
> initialized on input port and rte_eth_stats_get() shows uniform packet
> distribution (q_ipackets) among them, while q_errors remain zero for all
> queues. The only drop counter quickly increasing in the case of pure ACK
> flood is ierrors, while rx_nombuf remains zero.
>
> We tried different kinds of traffic generators, but always got the same
> result: 7Mpps (instead of expected 14Mpps) for TCP packets with ACK flag
> bit set while all other flag bits dropped. Source IPs and ports are
> selected randomly.
>
> Please let us know if anyone is aware of such strange behavior and where
> should we look at to narrow down the problem.
>
> Thanks in advance,
> Alexander Belyakov
>
>
>
>
>
> ===============================================================================
> Please refer to http://www.aricent.com/legal/email_disclaimer.html
> for important disclosures regarding this electronic communication.
>
> ===============================================================================
>