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 9AC8AA046B for ; Wed, 24 Jul 2019 09:52:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C34AD1C12B; Wed, 24 Jul 2019 09:52:44 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id D9E331C123 for ; Wed, 24 Jul 2019 09:52:42 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2019 00:52:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,302,1559545200"; d="scan'208";a="197415710" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 24 Jul 2019 00:52:40 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.164]) by IRSMSX101.ger.corp.intel.com ([169.254.1.88]) with mapi id 14.03.0439.000; Wed, 24 Jul 2019 08:52:40 +0100 From: "Ananyev, Konstantin" To: "Bly, Mike" , "'dev@dpdk.org'" CC: "Zhang, Qi Z" , "Lu, Wenzhuo" Thread-Topic: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs() Thread-Index: AdU9uzs3zrbn/k/UQnKadyHNENmvigDrjaAwAAFahLAAAH5CAAAMoUEAABKLnBA= Date: Wed, 24 Jul 2019 07:52:39 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772580168A5A51F@irsmsx105.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772580168A5A018@irsmsx105.ger.corp.intel.com> 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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNDc3MzE1MjAtNThiNi00ODlkLWFlMzItOTg5OTBjNTdhMzg4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYllkQnJ2OStIRlByZ1VmVktKWkZPRWtkQk81K04wTEJ4Y2FvVHZwejlNY21EbVBjMll4VlhBdk1sQTNSaHFhZSJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.180] 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" Hi Mike, > Konstantin, >=20 > The recommended use of rte_eth_tx_prepare() had no effect, which after lo= oking at it, makes sense. We are using "large" mbufs to support > Jumbo frames, so nb-seg will always =3D=3D 1. Additionally, we are not cu= rrently leveraging any HW offload capabilities. As such, > rte_eth_tx_prepare() always returns "num-frames". >=20 > Taking this a step further, I have reproduced the problem using a simple = c-unit test that builds bursts of frames, where each burst contains a > max-burst of frames (32 in our application), where the interleaved frames= have either a legal frame length (124-bytes) or intentionally a runt > frame length (20-bytes++). These are dumb-simple L2 frames, i.e. NOT ip-f= rames. The NIC is setup to pad and append, so it should just do > that without issue as needed. The test repeats this burst sequence a 100 = times, resulting in 3200 frames attempting to be transmitted. Run > to run, I am seeing anywhere from 750 to 3000 frames get transmitted. The= reafter, the NIC will no longer accept frames for transmit. Using > GDB, we have confirmed the same DD status problem is present and preventi= ng ixgbe_tx_free_bufs() from doing any actual freeing of > resources. >=20 > Is there a minimum runt size officially supported by DPDK and/or Intel on= the x550 NIC family? We could certainly do a simple frame-length > check and discard accordingly. However, we have seen 3rd party applicatio= ns send us runts, e.g. 40-byte ARP requests, over vhost-user and > tap interfaces, so we are a bit hesitant to blindly enforce this at 60 by= tes (min ETH minus CRC). AFAIK, sending frames smaller then 64B shouldn't cause a problem. At least I never hit such limitation. Qi, Wenzhuo - did you ever see such issue? My suggestion would be to open a new Bugzilla ticket for investigation and= =20 attach pcap file (or some scapy script to generate it) so it could be repro= duced with test-pmd. Thanks Konstantin =20 >=20 > -Mike >=20 > -----Original Message----- > From: Bly, Mike > Sent: Tuesday, July 23, 2019 10:08 AM > To: Ananyev, Konstantin ; 'dev@dpdk.org' > Subject: RE: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool= _get_regs() >=20 > Konstantin, >=20 > Thank you for the prompt reply on this posting. In looking at the single = use-case in test-pmd's csumonly.c, it would seem prepare + > retry_enabled may have some shortcomings as currently coded when nb_prep = < nb_rx. Has anyone looked at this? I happened to notice this > when looking for a reference for how it is expected to be used. It would = seem nb_rx should be replaced with nb_prep in the retry code. I > think the rest of the code should "just work" from there. Thoughts? >=20 > Regards, > Mike >=20 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Tuesday, July 23, 2019 9:03 AM > To: Bly, Mike ; 'dev@dpdk.org' > Subject: [**EXTERNAL**] RE: [dpdk-dev] x552 transmit issue and rte_ethtoo= l - rte_ethtool_get_regs() >=20 >=20 >=20 >=20 > > > > Hello, > > > > 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_bur= st(). All indications are the port is up and otherwise operational > and is still receiving traffic. It simply refuses to transmit anymore. > > > > Our application is running DPDK 17.05.1. In digging through the email > > archives, 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 describe: > > http://mails.dpdk.org/archives/dev/2017-August/073240.html > > http://inbox.dpdk.org/dev/b704af91-dcc6-4481-a54c-3e174b744d17.h.liu@a > > libaba-inc.com/ > > > > 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_get_regs() in the hopes that perhaps there would be somethi= ng 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 dumpe= d to the binary output file this API creates, for the x552 NIC? > Does anyone know if a decoder script exists? > > > > Other ideas to pursue? >=20 > It is hard to tell without any other information, but sometimes that happ= ens 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 RT= E_LIBRTE_ETHDEV_DEBUG is on. > Konstantin >=20 >=20 >=20