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 DCF8AA046B for ; Wed, 24 Jul 2019 01:09:57 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 21C121C0CA; Wed, 24 Jul 2019 01:09:57 +0200 (CEST) Received: from mx0a-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by dpdk.org (Postfix) with ESMTP id 250B01C0C4 for ; Wed, 24 Jul 2019 01:09:55 +0200 (CEST) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6NN7SDx026703; Tue, 23 Jul 2019 19:09:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ciena.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=06252019; bh=/OXu7lsKa53AuY4CFVMRnMePDZXCpCK9mCHl/kQShj8=; b=CasQNVatEysIR/PxauOwOTlnRmGI+Q5ee4yEfaqniem7N/27GgQOi6jhxXpiNUzLb1f7 tb9tmvKYRbFByMV20zELKFfUsMsESxkJVRZ2UNb0iUGoEri7AIXmGCeISFiuK5ReSgF3 ohvv5xusTaTDB+pakVh2iu+SncHzjnTN7c60wzl2X2S1pNKevNt0GwuPEMdvfscbaOdN oRdByCiKil30lVyJeBbnh/W4ovywf9O8H+IpBWBJF34E+sm3wG4+ohTI60GO+hEZOyB9 yghdGZvBUnCFQcTkRTNH2dqULDTjnKv5UsYwFDqz4ciU9ldG+k8MDGDP1KcmMu7DBhTo BA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2058.outbound.protection.outlook.com [104.47.32.58]) by mx0b-00103a01.pphosted.com with ESMTP id 2tx6181krb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 19:09:54 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UmY3GyGDYEEiEHuLomyuKsej+khLjgr+NaXaTioJ37y+pyqQk3e3IwbuBHjz4m48pyq7ZHGJ8v1HtJn50Bm4DZJRwExqTU80csyvpoXd+8/WounsyzA0+6LZlemSkEFGQ0kvxENMhRwd+z4h7F5qLDd6iOan3RcBiF0FL83+U/25L5RFMQH14AWV9lsI02PoS/kL5GAidPXeqECxCeNRoaohaDoZkPWkaTViSpekBMBUwaJd2WLZmCxQShuBrJPN/+5yWP662GG0ep6q+vCMetAIJcCaz1S4e+LIVASk6PKZ/lvLRoifLichTI/X4ZfbuH2r02LWlROxXANZ9dQPyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/OXu7lsKa53AuY4CFVMRnMePDZXCpCK9mCHl/kQShj8=; b=i6dafCEalGpt3OiZX3GD+Boc4C1cQu2AeciP5iWp7s1OemEBxIGtcMJSJ26Ccae87ggImtZbJSGhqQUmH9fu7+vT/cNpYhfg9yuvoTkdc5rVNp0A/wltR5eyGhZzNxfiHfId58zJ3tOhW7oB1y/Bv6bl9h/xP55X1PGUJ9+5MLrKIkEn4KvI7ZbTjWwI/BUsGhpA5KRejGlq2T7YkRqa2+W2rKXoTgOjH5/QDQHxu8sne9+B9G58zt2lW3pyHLP9iJqeqBed3bn152R4TPD2P0p8s1e94zHWt/9SAa7BbsggBoL+Y26Nn5ObyYZgvOjLg9XDUJ388+gmWkz3GAsRPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ciena.com;dmarc=pass action=none header.from=ciena.com;dkim=pass header.d=ciena.com;arc=none Received: from MWHPR04MB0592.namprd04.prod.outlook.com (10.173.49.145) by MWHPR04MB0480.namprd04.prod.outlook.com (10.173.52.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.15; Tue, 23 Jul 2019 23:09:52 +0000 Received: from MWHPR04MB0592.namprd04.prod.outlook.com ([fe80::a45f:7fde:28e4:8519]) by MWHPR04MB0592.namprd04.prod.outlook.com ([fe80::a45f:7fde:28e4:8519%7]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 23:09:52 +0000 From: "Bly, Mike" To: "Ananyev, Konstantin" , "'dev@dpdk.org'" Thread-Topic: [dpdk-dev] x552 transmit issue and rte_ethtool - rte_ethtool_get_regs() Thread-Index: AQHVQXAg9vjPmvftnkCp1nm+mPlQ5KbYbdCAgABgZMA= Date: Tue, 23 Jul 2019 23:09:52 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772580168A5A018@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [165.225.50.165] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62490aa1-f7e3-40ff-9c3e-08d70fc2dea2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7167020)(7193020); SRVR:MWHPR04MB0480; x-ms-traffictypediagnostic: MWHPR04MB0480: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0107098B6C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(136003)(396003)(39860400002)(189003)(199004)(13464003)(66476007)(76116006)(5660300002)(66556008)(66946007)(66066001)(66446008)(6246003)(478600001)(64756008)(55016002)(7736002)(305945005)(25786009)(256004)(229853002)(86362001)(6436002)(53936002)(74316002)(14444005)(52536014)(486006)(7696005)(2906002)(68736007)(316002)(76176011)(2940100002)(476003)(186003)(14454004)(81166006)(6506007)(53546011)(11346002)(102836004)(99286004)(446003)(55236004)(71190400001)(6306002)(9686003)(33656002)(26005)(8936002)(6116002)(966005)(81156014)(110136005)(71200400001)(3846002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR04MB0480; H:MWHPR04MB0592.namprd04.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: FQfQTie9FM1+l10skC+nu+fVpQZP0shoD174ua8K8Hm1qJyHR+CySu1YlXuRXiM+8h8HhoBlQ3m4kMsz4qKeTR68sFs7QNTOKMyOhwk3SCSI21wF+AuPu/9kDXc8SdMO1B+neayPSWCaCsKZyqtBaq4h1/SWAonjEI9oKDabM5K1bm0bx/i14w9P69k7r3146zPnHfT+I4/mQtRAb97MmhbBXFBLYfBM1YG4jdzGTBvh2GHNJxCWwaMehLhwmruK9VxaEHUWwPXx//0Sf8u0RhuPbHnm3FoAa+hzonBiOIzqR4szoQU3/Dh2dD1FZ9esnuEMWNOlDiswytMsseGgiLFE0xHcjT4polKPfCUmqZLtRiNpNthSfLNg/HcnHl7JkgdFLAHyCycM2epdpciBWbUKwfpy/v0hi4u2xEgYm8I= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62490aa1-f7e3-40ff-9c3e-08d70fc2dea2 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 23:09:52.8564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mbly@ciena.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR04MB0480 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-23_09:2019-07-23,2019-07-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 adultscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1907230237 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" Konstantin, The recommended use of rte_eth_tx_prepare() had no effect, which after look= ing 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 currently leverag= ing any HW offload capabilities. As such, rte_eth_tx_prepare() always retur= ns "num-frames". 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-bur= st of frames (32 in our application), where the interleaved frames have eit= her a legal frame length (124-bytes) or intentionally a runt frame length (= 20-bytes++). These are dumb-simple L2 frames, i.e. NOT ip-frames. The NIC i= s setup to pad and append, so it should just do that without issue as neede= d. The test repeats this burst sequence a 100 times, resulting in 3200 fram= es attempting to be transmitted. Run to run, I am seeing anywhere from 750 = to 3000 frames get transmitted. Thereafter, the NIC will no longer accept f= rames for transmit. Using GDB, we have confirmed the same DD status problem= is present and preventing ixgbe_tx_free_bufs() from doing any actual freei= ng of resources. Is there a minimum runt size officially supported by DPDK and/or Intel on t= he x550 NIC family? We could certainly do a simple frame-length check and d= iscard accordingly. However, we have seen 3rd party applications send us ru= nts, e.g. 40-byte ARP requests, over vhost-user and tap interfaces, so we a= re a bit hesitant to blindly enforce this at 60 bytes (min ETH minus CRC). -Mike -----Original Message----- From: Bly, Mike=20 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_g= et_regs() Konstantin, Thank you for the prompt reply on this posting. In looking at the single us= e-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? Regards, Mike -----Original Message----- From: Ananyev, Konstantin =20 Sent: Tuesday, July 23, 2019 9:03 AM To: Bly, Mike ; 'dev@dpdk.org' Subject: [**EXTERNAL**] RE: [dpdk-dev] x552 transmit issue and rte_ethtool = - rte_ethtool_get_regs() >=20 > Hello, >=20 > We are chasing an interesting NIC transmit issue where after some=20 > period of time with normal operation the NIC enters a state where it=20 > 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 sti= ll receiving traffic. It simply refuses to transmit anymore. >=20 > Our application is running DPDK 17.05.1. In digging through the email=20 > archives, this appears to be related to the following posts, as we see th= e same nb_free =3D 0 and IXGBE_ADVTXD_STAT_DD not set problems they describ= e: > 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/ >=20 > Having not seen any resolution on the above DPDK posts and after a=20 > number of other investigative steps, we incorporated the rte_ethtool=20 > lib to provide the ability to dump the NIC register set via=20 > rte_ethtool_get_regs() in the hopes that perhaps there would be something= there in a status register to point us in the right direction. The questio= n 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 if = a decoder script exists? >=20 > Other ideas to pursue? It is hard to tell without any other information, but sometimes that happen= s 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