Hello,
On Sat, Nov 2, 2013 at 9:29 AM, Prashant Upadhyaya < prashant.upadhyaya at 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 at 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. > > =============================================================================== >
