From mboxrd@z Thu Jan 1 00:00:00 1970 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) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nW5mhlGHEVsR2DO23EMA9gaILXxMUha9KtWoL1+omio=; b=UZdWFlUxXcyN8149zmZZEx3UO/JXvUe67crLs+N1alRjlSX2k+FW4jZf2NRV6jhl+j 0YrCOGeKkLJbDvRyS+IR762oRqM21lv10rJgttzC+nxRuOqgqHKGwbiONcaYDUewMpvc QGgWlxkArJUZh35FprRYZVxprsoNTNQlVHLqKnesuvHEFP0rs3XdtSOoskNj4MwN2qKo g2+dQ0ScQla/VKTd/JiwsT+if4Xc/QWQiSp605/a390q5R2aarfidVzyMViBBc6rld/I fPGGTDu2s9ZIaWthkOMK5IG4zBKJ5zn19fFfCdAWIeBWPMBOswxC/WnJOa9tfoXE3Fe+ RIjw== X-Gm-Message-State: ALoCoQn4KAFwFvCw9l3lJtQxNrCZcIrOcHSat0sd/Xn977KST5s37XTKB+NatL1lEOZjBHqghqrT X-Received: by 10.180.83.65 with SMTP id o1mr17292443wiy.14.1437659816625; 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) Message-ID: <55B0F2A7.5020400@linaro.org> Date: Thu, 23 Jul 2015 14:56:55 +0100 From: Zoltan Kiss User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "dev@dpdk.org" References: <55B0CCBE.4000707@linaro.org> In-Reply-To: <55B0CCBE.4000707@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] ixgbe packet drops not accounted for 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: Thu, 23 Jul 2015 13:56:56 -0000 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