From patchwork Wed Jan 18 02:05:57 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yong Wang X-Patchwork-Id: 19687 Return-Path: X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id 0A02F2B83; Wed, 18 Jan 2017 03:06:04 +0100 (CET) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0050.outbound.protection.outlook.com [104.47.34.50]) by dpdk.org (Postfix) with ESMTP id 4B4B9100F for ; Wed, 18 Jan 2017 03:06:01 +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=5gVCW6y+S6BUoQiBDj+mHbxTvi/Pho8d1AGeP6R6Es0=; b=C5MbOAfxoYFzuOGgb0sug8dr5wI8DlCVuWYuPI4z5aYB4eHHh8PEYdjXem2Ec1mtmRxsu9DexNpzGvZCGNtbowB0B8XTIjZiy+10I2W1eBNM/Sk1Y7awxrjjNRQouSUhJpmp9CW9yVlNSoHcw/5vCBI9ujxTKu9/bEBouxrUuKA= Received: from BY2PR05MB2359.namprd05.prod.outlook.com (10.166.113.11) by BY2PR05MB2359.namprd05.prod.outlook.com (10.166.113.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 02:05:58 +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.0860.012; Wed, 18 Jan 2017 02:05:58 +0000 From: Yong Wang To: nickcooper-zhangtonghao CC: "ferruh.yigit@intel.com" , "dev@dpdk.org" Thread-Topic: [PATCH v3 1/4] vmxnet3: Avoid memory leak in vmxnet3_dev_rx_queue_setup. Thread-Index: AQHSaiSRZ71EQlMaR02t5RdRGMdeNqE9IPHggABhlYCAAAcVcA== Date: Wed, 18 Jan 2017 02:05:57 +0000 Message-ID: References: <1483930780-7064-1-git-send-email-nic@opencloud.tech> In-Reply-To: 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: 618c5ac7-f698-4135-0323-08d43f468b50 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BY2PR05MB2359; x-microsoft-exchange-diagnostics: 1; BY2PR05MB2359; 7:Gh/edqD9pWCo9wBF1o80ZaJ2sMJlXbWHNG93UFGCiZbaFVtdMKhP4mZJ7o0Iqan3aOEfsqzHQvQzlNsBboi82XbsLpto50HEFJqp/LHhFtjc5znAteKeeO9ZyQ3KaxHoY1NsAPUVY1tR/EM6C/AgLqSCK8hftwws4eizy3sjiWJ33GemuDe3WDHgg8kULNIT8NFlBcDALnA/4f6w5FQmlJuIciCy5NT47/iGb4r1CPJLTJIetETi2RYyHJP4yzFEEDmt8l/sF6L0gxp8hzjWqLm33/qo5JDk4HMAPg3HSDiafK3xfpFQsZ+pDXcJ164YIZ7dG5YX8fK1DWbuoPV5S57fDBAtdP34W4OLd/yMN0DJwjrfNYr0LjnlVzvGUi35YEoIPta2TDhrPcIv997BlRirWzqjoxfVKpUjSB+PSIb9Hx0OVvzOjdQdOlusfcfK8zdgRNMiPRekvw75J0Reqw==; 20:xzdDtx8rHXgN7VyViC4SRygDuWOHnOjbv075AQf836gw4+Mlr3hXnmL8xyMxv3t/CbfjTNPAm65r8BMhsRdBlA+A3etLJAW0Invq80kZJrX1Od+aL8aicuBc61yQu+/Mk7Xo/aQTGT/rfs0m3alLnyMLjHG9AK96fyUzQTHqr9c= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(21748063052155)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123564025)(20161123562025)(6042181)(6072148); SRVR:BY2PR05MB2359; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB2359; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(13464003)(377454003)(24454002)(199003)(66066001)(6116002)(790700001)(102836003)(8936002)(6916009)(2950100002)(38730400001)(6436002)(6506006)(105586002)(77096006)(74316002)(106116001)(7736002)(3846002)(9686003)(4326007)(236005)(8676002)(53946003)(81156014)(7696004)(81166006)(2906002)(5660300001)(3280700002)(3660700001)(110136003)(68736007)(55016002)(6306002)(54896002)(86362001)(50986999)(54356999)(76176999)(229853002)(189998001)(33656002)(101416001)(54906002)(2900100001)(97736004)(25786008)(92566002)(99286003)(122556002)(106356001)(53936002)(15760500002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB2359; 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 MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 02:05:58.0036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB2359 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 1/4] vmxnet3: Avoid memory leak in vmxnet3_dev_rx_queue_setup. 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" Any downside with free/reallocation now that memzone can be freed? Allocation with max ring size should work but is kind of wasteful in terms of memory usage and I assume this type of ring size change should not be a frequent operation. From: nickcooper-zhangtonghao [mailto:nic@opencloud.tech] Sent: Tuesday, January 17, 2017 5:37 PM To: Yong Wang Cc: ferruh.yigit@intel.com; dev@dpdk.org Subject: Re: [PATCH v3 1/4] vmxnet3: Avoid memory leak in vmxnet3_dev_rx_queue_setup. On Jan 18, 2017, at 4:15 AM, Yong Wang > wrote: -----Original Message----- From: Nick Zhang [mailto:nic@opencloud.tech] Sent: Sunday, January 8, 2017 7:00 PM To: Yong Wang > Cc: ferruh.yigit@intel.com; dev@dpdk.org; Nick Zhang > Subject: [PATCH v3 1/4] vmxnet3: Avoid memory leak in vmxnet3_dev_rx_queue_setup. This patch will check the "nb_desc" parameter for rx queue. Rx vmxnet rings length should be between 128-4096. The patch will release the rxq and re-allocation it soon for different "nb_desc". Signed-off-by: Nick Zhang > --- drivers/net/vmxnet3/vmxnet3_rxtx.c | 30 ++++++++++++++++++------------ 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c index b109168..e77374f 100644 --- a/drivers/net/vmxnet3/vmxnet3_rxtx.c +++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c @@ -926,6 +926,21 @@ PMD_INIT_FUNC_TRACE(); + /* Rx vmxnet rings length should be between 128-4096 */ + if (nb_desc < VMXNET3_DEF_RX_RING_SIZE) { + PMD_INIT_LOG(ERR, "VMXNET3 Rx Ring Size Min: 128"); + return -EINVAL; + } else if (nb_desc > VMXNET3_RX_RING_MAX_SIZE) { + PMD_INIT_LOG(ERR, "VMXNET3 Rx Ring Size Max: 4096"); + return -EINVAL; + } + + /* Free memory prior to re-allocation if needed. */ + if (dev->data->rx_queues[queue_idx] != NULL) { + vmxnet3_dev_rx_queue_release(dev->data->rx_queues[queue_idx]); Currently vmxnet3_dev_rx_queue_release() does not free device ring memory. As a result, the same device ring memory allocated based on the previous descriptor size will be used and that should also explain why you are observing seg fault with an increased ring size. If you handle the device ring memory free in vmxnet3_dev_rx_queue_release(), I think the pre-allocation of ring with max size will not be needed any more. Yes, we should not free the pre-allocation of ring, but alloc only once ring with max size. I will submit v4. Thank you.