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. 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] 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] Regards -Prashant -----Original Message----- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Alexander Belyakov Sent: Friday, November 01, 2013 7:13 PM To: dev at 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. ===============================================================================
