From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 63932A046B for ; Tue, 23 Jul 2019 18:03:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A17871C08E; Tue, 23 Jul 2019 18:03:06 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 225E21C07B for ; Tue, 23 Jul 2019 18:03:04 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2019 09:03:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,299,1559545200"; d="scan'208";a="321043640" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga004.jf.intel.com with ESMTP; 23 Jul 2019 09:03:02 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX107.ger.corp.intel.com ([169.254.10.251]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 17:03:02 +0100 From: "Ananyev, Konstantin" To: "Bly, Mike" , "'dev@dpdk.org'" Thread-Topic: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs() Thread-Index: AdU9uzs3zrbn/k/UQnKadyHNENmvigDrjaAwAAFahLA= Date: Tue, 23 Jul 2019 16:03:01 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580168A5A018@irsmsx105.ger.corp.intel.com> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmJkYTkwOGItNjE4Ny00NGViLWJmOTEtMDc1YjJhZDQ5ZDA5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoidXd6Tlp5UmxIeFo4Y1llNms2R0toZlFZeGVVaDcrQjhyVk9wRDZ1WVwvVjgya0JBa1pvRE43dFNNSUZvVUc1U2MifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs() X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >=20 > Hello, >=20 > We are chasing an interesting NIC transmit issue where after some period = of time with normal operation the NIC enters a state where it > refuses to transmit frames from our DPDK application via rte_eth_tx_burst= (). All indications are the port is up and otherwise operational and > is still receiving traffic. It simply refuses to transmit anymore. >=20 > Our application is running DPDK 17.05.1. In digging through the email arc= hives, this appears to be related to the following posts, as we see > the same nb_free =3D 0 and IXGBE_ADVTXD_STAT_DD not set problems they des= cribe: > http://mails.dpdk.org/archives/dev/2017-August/073240.html > http://inbox.dpdk.org/dev/b704af91-dcc6-4481-a54c-3e174b744d17.h.liu@alib= aba-inc.com/ >=20 > Having not seen any resolution on the above DPDK posts and after a number= of other investigative steps, we incorporated the rte_ethtool > lib to provide the ability to dump the NIC register set via rte_ethtool_g= et_regs() in the hopes that perhaps there would be something there > in a status register to point us in the right direction. The question now= is what is the best way to check the register contents dumped to the > binary output file this API creates, for the x552 NIC? Does anyone know i= f a decoder script exists? >=20 > Other ideas to pursue? It is hard to tell without any other information, but sometimes that happen= s=20 when user tries to TX malformed packet. Might be worth to try using rte_eth_tx_prepare() inside your app. It does some sanity checks to prevent such situations, especially when RTE_= LIBRTE_ETHDEV_DEBUG is on. Konstantin=20