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 A867FC33A for ; Thu, 23 Jul 2015 13:15:11 +0200 (CEST) Received: by wicmv11 with SMTP id mv11so19116264wic.0 for ; Thu, 23 Jul 2015 04:15:11 -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:content-type:content-transfer-encoding; bh=2Vr0zKGsyU9EcOJhI7tq0CUrtWmxL7zVw02MgwtzzMI=; b=QfOBMecm/9oNMOMkGkVqVBReJZNpWF7zw7uMEg7RYQzR2voJYc3ko4YPPGDiTqVxbY XPEGlW6nzhEt2W3rwVgY1Jzer4stZK70rWmeZukCaYmOciqIRhwYFiSCWaNuEnGGx6vi MMQgSPC+VBAtLmmyhdeyWghQseNYMDs6qTrpW9jsCKLGFlm5iAV9DMdU0VF3nUIqnIoZ 7nFmBzs2S4/OpWioimc8DqP1Ne0sw1Fdj9MnryAckzYL4wT3qaBJov8LeZPd6xDnmjoB cMS7z0UzQK2yWkkEpVUH3w89yP2qj/HoKLAEGR2pB8X4VZgmv2XuA0Qa1yk9PCuG6CW3 9pWw== X-Gm-Message-State: ALoCoQlSBEXXo7MzY1QRoV1PDn5/IQivxfeLOkH8LXCU6UzLDNezcV4jsgiee4salF2c/leD0eE9 X-Received: by 10.180.95.197 with SMTP id dm5mr24732273wib.93.1437650111481; Thu, 23 Jul 2015 04:15:11 -0700 (PDT) Received: from [192.168.0.101] ([90.152.119.35]) by smtp.googlemail.com with ESMTPSA id l6sm26650465wib.18.2015.07.23.04.15.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2015 04:15:10 -0700 (PDT) Message-ID: <55B0CCBE.4000707@linaro.org> Date: Thu, 23 Jul 2015 12:15:10 +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" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [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 11:15:11 -0000 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