From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by dpdk.org (Postfix) with ESMTP id 8A98B156 for ; Sun, 3 Nov 2013 21:31:45 +0100 (CET) Received: by mail-qc0-f180.google.com with SMTP id e9so3556143qcy.39 for ; Sun, 03 Nov 2013 12:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f426s84Pnvc11SPgB4Ro2tc44ymnT1L4VMGqThHC2Es=; b=0hyuAZ4KdP4+3Y7Hlm/Y8DBxz+pCglV7mWg7PjjSjwGWfdd8JqQdQF8bes2RtEMft+ XwLp1QYjoStrGsAr4w8Ep4yKnjKHnfsSSSCs1eHVqBhZxFuSC+77Xry8qDeOg/6+toaL O1KLJhCDeB2RJ/j+GLDrDzo4Ee5GUE2/I/ZpRnViNxL5hwawp3sH4gFeylOmxunDEDd/ E4FawUaT2MXhsjSgIyEO88rT6rAxcUVG/4r7DtjkvEZSeT3bdtpobvBgGcrRAS8eiivJ aYGsel6czavP1c5cGyYisueNU4HFJhOUqX2Zy8PiZuEE2kVHN7hT4jBw2GIvdI6sfvaW 7gtw== MIME-Version: 1.0 X-Received: by 10.224.80.4 with SMTP id r4mr18163056qak.69.1383510758059; Sun, 03 Nov 2013 12:32:38 -0800 (PST) Received: by 10.140.27.4 with HTTP; Sun, 3 Nov 2013 12:32:38 -0800 (PST) In-Reply-To: References: Date: Mon, 4 Nov 2013 00:32:38 +0400 Message-ID: From: Alexander Belyakov To: Prashant Upadhyaya Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Surprisingly high TCP ACK packets drop counter X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 20:31:46 -0000 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. > > =============================================================================== >