From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by dpdk.org (Postfix) with ESMTP id 3FFBD95C5 for ; Fri, 13 Nov 2015 17:32:28 +0100 (CET) Received: by ioir85 with SMTP id r85so61781862ioi.1 for ; Fri, 13 Nov 2015 08:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infiniteio_com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:content-type; bh=RCbHHLn2r9Dn1nAvowlQLrRpk2A43z0ZmYnqIZ1LDbY=; b=zp4eBNPRgDEhqPHAijkNJjudcYnhNyCNscBViQR9HidFKKFlZmAxobyHGHN8IuQ+Bc 6GTk8opS2ghcKy01BNohRVkhl6m0QrBwG/tQ/yYwODCsrhz0HCLMQXqpuVpeK0TecXKK KSCIQjbOVESL/Rsi5MNeKzIn4h1R2+snWNJmQdtxRDqrkcwp2aFt/X+hnvxJcObQyqsg kXzmdeRwp5mvEaJi56aJP9B8aPAeUy8o7b3b4Ml/mLJzDheyjesDJ92p6fX+IG0Lqvgw ZDcxKfFY5FDbqRl01+d5vPwdgS4qwpIfUIMFWxteQLa6B8E5qF5L8a+bqAWZan2gjiAx RKLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RCbHHLn2r9Dn1nAvowlQLrRpk2A43z0ZmYnqIZ1LDbY=; b=Z+Y9+AlfKV5j7mmAtzoJhlQU92E1k2MW3iTy9UhkV/Wunl/4bAlbjy9MbINBe0B6ob oJmYZSDeNkR4E+W68GRNoRh31saMlwbRtFrnSPXiwygbNwMy+L6m5zVM+H9JEctnxPrj sDMD17pto5V/VCDIW9cY7h7pesQ9pj5MWrSGynpyis89ruLqwi/BncZh7nF7QrfcmhGQ EMJG+Tdqs/sW/U7PyHLWlyBkhSV7prajHpEExGAjw7l08+M/BIUZ16PZ0ondPl6IuBCP D1+g4BsyUzcX6LFJyUfpci29w+P6obTbfd9kOPO1R/P6V2PdN/0j0Ogj9aTAUGHSjffK p0JQ== X-Gm-Message-State: ALoCoQmoETnleVXOSyewF/UCGYk8/9U5T2VJDLfJ7KAlptssYxuny8x0aDCo9r32dmEqsJteraVb MIME-Version: 1.0 X-Received: by 10.107.154.67 with SMTP id c64mr19025429ioe.53.1447432347568; Fri, 13 Nov 2015 08:32:27 -0800 (PST) Received: by 10.107.140.15 with HTTP; Fri, 13 Nov 2015 08:32:27 -0800 (PST) Date: Fri, 13 Nov 2015 10:32:27 -0600 Message-ID: From: Matt Laswell To: users Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] How to approach packet transmit failures X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 16:32:28 -0000 Hey Folks, I'm dealing with a situation in which my application loses the ability to transmit packets out of a port during times of moderate stress. I'd love to hear suggestions for how to approach this problem, as I'm a bit at a loss at the moment. Specifically, I'm using DPDK 1.6r2 running on Ubuntu 14.04LTS on Haswell processors. I'm using the 82599 controller, configured to spread packets across multiple queues. Each queue is accessed by a different lcore in my application; there is therefore concurrent access to the controller, but not to any of the queues. We're binding the ports to the igb_uio driver. The symptoms I see are these: - All transmit out of a particular port stops - rte_eth_tx_burst() indicates that it is sending all of the packets that I give to it - rte_eth_stats_get() gives me stats indicating that no packets are being sent on the affected port. Also, no tx errors, and no pause frames sent or received (opackets = 0, obytes = 0, oerrors = 0, etc.) - All other ports continue to work normally - The affected port continues to receive packets without problems; only TX is affected - Resetting the port via rte_eth_dev_stop() and rte_eth_dev_start() restores things and packets can flow again - The problem is replicable on multiple devices, and doesn't follow one particular port I've tried calling rte_mbuf_sanity_check() on all packets before sending them. I've also instrumented my code to look for packets that have already been sent or freed, as well as cycles in chained packets being sent. I also put a lock around all accesses to rte_eth* calls to synchronize access to the NIC. None of these strategies proved effective. Like I said at the top, I'm a little at a loss at this point. If you were dealing with this set of symptoms, how would you proceed? Thanks in advance. -- Matt Laswell infinite io, inc. laswell@infiniteio.com