From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zoltan Kiss Subject: Re: ixgbe packet drops not accounted for Date: Thu, 23 Jul 2015 14:56:55 +0100 Message-ID: <55B0F2A7.5020400@linaro.org> References: <55B0CCBE.4000707@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: "dev@dpdk.org" Return-path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id BA976C370 for ; Thu, 23 Jul 2015 15:56:56 +0200 (CEST) Received: by wibxm9 with SMTP id xm9so150643488wib.1 for ; Thu, 23 Jul 2015 06:56:56 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id lq9sm7662126wjb.35.2015.07.23.06.56.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 06:56:55 -0700 (PDT) In-Reply-To: <55B0CCBE.4000707@linaro.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Never mind, I've digged a bit more in the sink's driver stats, it turned out there are a lot of RX misses when it receives through the test box. Increasing the RX ring from 512 to 2048 solved the issue. I guess the change in the burst pattern caused this whole issue. Regards, Zoltan On 23/07/15 12:15, Zoltan Kiss wrote: > Hi, > > I've seen an odd behaviour in my test setup, which affected my test > results, so I set up a much simpler scenario. > I'm using netmap pktgen as a packet source, it creates a steady 14.2 > Mpps of 64 byte UDP packets over one port of a 82599ES dual port card. > This traffic then goes to an another similar machine with the same dual > port NIC, where it get forwarded out on the other port. The packet sink > runs on the same machine as the generator, it's also netmap pktgen, and > it tells me there is a big fluctuation of throughput between 13 and 14 > Mpps, the average comes out around 13.4 Mpps. After I've stripped down > my test app to nothing but calling rx and tx functions in a loop (it > doesn't even modifies the MAC address as DPDK l2fwd does), I've started > to check what rte_eth_tx_burst() tells us. I've added it's return value > to a counter, and a separate thread printed it out every second > (sleep(1)), and I've found it reports a steady 14.05 Mpps output. I've > checked with rte_eth_stats_get(), it gives me the same numbers, and no > indication of any failure. > When I've connected the generator to the sink directly, it was able to > receive all the packets, so it's not that the sink is not able to count > them all. I've even replaced the cables with each other to see if the > one towards the sink drops some packets, but nothing changed. > I had the impression that once rte_eth_tx_burst() managed to place the > packets on the descriptor ring, it will go out in some finite time, or > if the card itself drops it, it will appear in the stats at least, but > the oerrors and q_errors values are always 0. > Does anyone has an idea where could those packets (avg 0.6 Mpps) get > dropped? > > Regards, > > Zoltan Kiss