From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0042.outbound.protection.outlook.com [104.47.42.42]) by dpdk.org (Postfix) with ESMTP id 15E014CC5 for ; Fri, 16 Dec 2016 18:47:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qVJCZY0qLHemPc4KHBIA3dCGDYUscfpMG6795DytbCk=; b=m33QuGM16UNDUqa8Qzt/363YPSrJBDRXzfUw0gE3JWbDWMispn3y2gpTy840bFw5FNgd0y14LF2OZwRivM8v9wX1QjBiTviCKmxBz9ji/KtNcsKNkCyXJHAckPGvXu3VHAO4kyrvc2xIgo47+ZYkD3HGQ4SBRo9tXGPZ8Lqk85I= Received: from BY2PR05MB2359.namprd05.prod.outlook.com (10.166.113.11) by BY2PR05MB2360.namprd05.prod.outlook.com (10.166.113.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.5; Fri, 16 Dec 2016 17:47:47 +0000 Received: from BY2PR05MB2359.namprd05.prod.outlook.com ([10.166.113.11]) by BY2PR05MB2359.namprd05.prod.outlook.com ([10.166.113.11]) with mapi id 15.01.0789.014; Fri, 16 Dec 2016 17:47:47 +0000 From: Yong Wang To: Stefan Puiu , "dev@dpdk.org" CC: "mac_leehk@yahoo.com.hk" Thread-Topic: [PATCH v3] vmxnet3: fix Rx deadlock Thread-Index: AQHSV7JjkPlDmOtIukCpw5sF2JH6eaEK1sMQ Date: Fri, 16 Dec 2016 17:47:47 +0000 Message-ID: References: <1481530874-8660-1-git-send-email-stefan.puiu@gmail.com> <1481902617-16050-1-git-send-email-stefan.puiu@gmail.com> In-Reply-To: <1481902617-16050-1-git-send-email-stefan.puiu@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yongwang@vmware.com; x-originating-ip: [208.91.1.34] x-ms-office365-filtering-correlation-id: 4bc1fe2f-ff8f-46e2-ef1e-08d425dba5b3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR05MB2360; x-microsoft-exchange-diagnostics: 1; BY2PR05MB2360; 7:GgOUjTFSbm2cO9XbGJMwfrfEd3I9gHttOkbAlZ167x2A0gEPEbGnoeiOgx/KqgZZj/ksrJhfVLnZZnik8sYUxLiTUsRzz6eSUZTBXxDPeuQJb+dGWCIMwrTJJ7GQIKdTy/LM/euqEV9Lgd4Rcd7BSXeTn1YIH4X4C+m5+UHD2ZhFfztv37HYU/aS2zqJ12Xaafgaf0QdL4p9BoqIZ75Zn0hhkA/PhdiQyRIDl9XS8f46i8XMoOXFQSby1XEOvtUl+0tLsPkpRvpAGSNHRvvmOeatttcyBkkKuDU+4B0Ke6cj/VJ1fLFsnepuTx8vYf+s+sjf+SYv/hCsy+dD0acxnKqSne8MdxSUEp1iaIwxdkl1lcFbCkPcqic+wUhoehMdOwZoR5WzgxgSwlUpSnaiEPQ18pPa3BekvSj8p6O/IeB3hQ+6nWb9iqC8JKKRtamkcEPLk1AzakOKw1T0iVZhmQ==; 20:kdSl/j2K3fQZET/yhQilAWtqacx/iu7dp6LW6zGbIxjLaCnFp5G3LjywUqH5TlAXRFd8FYOqP+x1CFssxb7ZpSt/JNoxtMOVvv2++3vGw/M5wTAtJUY+9IBVy/+HkWDfuN5hAd8BV1/yAq6+EJqKGI8AW7cKGz5tzgjezjuXPe4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(10436049006162)(214293980204627); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558021)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BY2PR05MB2360; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2360; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(13464003)(199003)(50986999)(54356999)(76176999)(2906002)(7696004)(76576001)(7736002)(2900100001)(6116002)(305945005)(2950100002)(74316002)(99286002)(92566002)(3846002)(102836003)(33656002)(105586002)(5660300001)(106356001)(106116001)(9686002)(68736007)(38730400001)(77096006)(39060400001)(6506006)(3280700002)(2501003)(122556002)(8936002)(229853002)(97736004)(189998001)(25786008)(66066001)(81156014)(6436002)(81166006)(5001770100001)(575784001)(8676002)(4326007)(3660700001)(86362001)(101416001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB2360; H:BY2PR05MB2359.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Dec 2016 17:47:47.0497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2360 Subject: Re: [dpdk-dev] [PATCH v3] vmxnet3: fix Rx deadlock 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: , X-List-Received-Date: Fri, 16 Dec 2016 17:47:49 -0000 > -----Original Message----- > From: Stefan Puiu [mailto:stefan.puiu@gmail.com] > Sent: Friday, December 16, 2016 7:37 AM > To: dev@dpdk.org > Cc: Yong Wang ; mac_leehk@yahoo.com.hk; > Stefan Puiu > Subject: [PATCH v3] vmxnet3: fix Rx deadlock >=20 > Our use case is that we have an app that needs to keep mbufs around > for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from > vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX > descriptors (where it returns -err). Since there are no mbufs that the > virtual hardware can use, no packets will be received after this; the > driver won't refill the mbuf after this so it gets stuck in this > state. I call this a deadlock for lack of a better term - the virtual > HW waits for free mbufs, while the app waits for the hardware to > notify it for data (by flipping the generation bit on the used Rx > descriptors). Note that after this, the app can't recover. >=20 > This fix is a rework of this patch by Marco Lee: > https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__dpdk.org_dev_patchwork_patch_6575_&d=3DDgIBAg&c=3DuilaK90D4TOVo > H58JNXRgQ&r=3Dv4BBYIqiDq552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=3DzvM > IQvFmKNiehiMa4e9UerIU- > XZTcnlOqJZ0FXx0lsM&s=3DnZk5Zsz_6yrZOCrteBQ4RJbgLMhsPxW8DQkZmzGSo > yU&e=3D . I had to forward port > it, address review comments and also reverted the allocation > failure handling to the first version of the patch > (https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > 3A__dpdk.org_ml_archives_dev_2015- > 2DJuly_022079.html&d=3DDgIBAg&c=3DuilaK90D4TOVoH58JNXRgQ&r=3Dv4BBYIqiD > q552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=3DzvMIQvFmKNiehiMa4e9UerI > U-XZTcnlOqJZ0FXx0lsM&s=3DdU2FsdH7OPHIUXeXIrv0yubdCb- > 4_koMclojVj_5ULo&e=3D ), since > that's the only approach that seems to work, and seems to be what > other drivers are doing (I checked ixgbe and em). Reusing the mbuf > that's getting passed to the application doesn't seem to make > sense, and it was causing weird issues in our app. Also, reusing > rxm without checking if it's NULL could cause the code to crash. > --- Signoff info is missing from the commit description. Otherwise, looks good= . Acked-by: Yong Wang