From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) by dpdk.org (Postfix) with ESMTP id 241E3298F for ; Thu, 9 Jun 2016 20:42:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BivioNetworks.onmicrosoft.com; s=selector1-bivio-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wekOZ4EOUKfYF79Jlp9g4MX6mtPGA0IGUH0yqpNct7o=; b=Xk7To5WpMMkv/MFfdHeCwp1F7Jy06tHx4RlQ1SNr1vu+I/K+yyFHqZslKm+QJPBM6f/2sr187BgEjN0q5/P7ao5NbO9MNdXRgVc1xTsA9tMNJpFyZusIBUBnDbABeBNEfz0dNAP7JX0nz1jaPIh6XlfCaN3OOMcRpzKP1d6xy5s= Received: from CY1PR0101MB0987.prod.exchangelabs.com (10.160.224.149) by CY1PR0101MB0987.prod.exchangelabs.com (10.160.224.149) with Microsoft SMTP Server (TLS) id 15.1.497.12; Thu, 9 Jun 2016 18:42:27 +0000 Received: from CY1PR0101MB0987.prod.exchangelabs.com ([10.160.224.149]) by CY1PR0101MB0987.prod.exchangelabs.com ([10.160.224.149]) with mapi id 15.01.0497.015; Thu, 9 Jun 2016 18:42:27 +0000 From: Don Provan To: "Ananyev, Konstantin" , Thomas Monjalon CC: "dev@dpdk.org" , Olivier Matz , Adrien Mazarguil , "Zhang, Helin" Thread-Topic: [dpdk-dev] [PATCH] mbuf: remove inconsistent assert statements Thread-Index: AQHRwmfgvTD2n9MPA0uO+DEnGBfCj5/hdP2Q Date: Thu, 9 Jun 2016 18:42:26 +0000 Message-ID: References: <1465374688-11729-1-git-send-email-adrien.mazarguil@6wind.com> <57591EEA.9040807@6wind.com> <2601191342CEEE43887BDE71AB97725836B6D90C@irsmsx105.ger.corp.intel.com> <11387408.tmVAJa3yAF@xps13> <2601191342CEEE43887BDE71AB97725836B6DA64@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836B6DA64@irsmsx105.ger.corp.intel.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=dprovan@bivio.net; x-originating-ip: [209.234.132.35] x-ms-office365-filtering-correlation-id: d2a32e96-be33-4e10-221b-08d39095ce1c x-microsoft-exchange-diagnostics: 1; CY1PR0101MB0987; 5:MQdANCd6Umu9SFnIo1nMhK+ognQ2UkSHVHhOdGOboboyo9uV5GQzCc410Ov0wCxNvX9Oye2ZmEjnqgGT05PGTF5KEqWB+7OUKGdy7rWcxivybJfDir/L9d9w2z0HQ2QyOusOK2K/aDYq2lmp3j7cKQ==; 24:5V5bOo4BsiP1uS39enDIZujKWDg+7z9+Kw9A5Kbb68L0i2yWOp1Cqo/MzlF3qZ02FA/b9sXaAnQL4eowb0bvlUQG3qzB28lRaasWMnz6dHQ=; 7:tVkv6fsc7uxx8KIGac8hBPxbvQUYbQCPKky5aFm+DYoJuqKmqNdV4znTtnnyV2JhyjSu6xMEhYQfg14a1zpVM5wqBQCfmg0Wdq91LxT1UodJNZ2SEYDJHL9PjPkRl6kEpxuRcPvvuGEr4rNAvPpUQOMpCjw2D0bQsfJYNOmOHgHXQJj0vN3F5MuEWCrMomd3aXCGDFretRmT8PcBaNq2tw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0101MB0987; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041072)(6043046); SRVR:CY1PR0101MB0987; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0101MB0987; x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(189002)(19580395003)(19580405001)(77096005)(74316001)(92566002)(5004730100002)(8676002)(106116001)(105586002)(5002640100001)(9686002)(5008740100001)(106356001)(11100500001)(5003600100002)(2906002)(2950100001)(8936002)(2900100001)(3660700001)(76176999)(50986999)(54356999)(87936001)(68736007)(3280700002)(3846002)(102836003)(6116002)(101416001)(81156014)(81166006)(93886004)(66066001)(4326007)(10400500002)(86362001)(189998001)(122556002)(97736004)(33656002)(5001770100001)(586003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB0987; H:CY1PR0101MB0987.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bivio.net 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: bivio.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2016 18:42:26.8880 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8731bc55-0e76-4eb7-ae4b-401e56037945 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB0987 Subject: Re: [dpdk-dev] [PATCH] mbuf: remove inconsistent assert statements X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 18:42:29 -0000 > -----Original Message----- > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]=20 > Sent: Thursday, June 09, 2016 8:45 AM > To: Thomas Monjalon > Cc: dev@dpdk.org; Olivier Matz ; Adrien Mazarguil= ; Zhang, Helin > Subject: Re: [dpdk-dev] [PATCH] mbuf: remove inconsistent assert statemen= ts >... > But as I said, if everyone are that desperate about symmetry, we can just= create a new public function: > > void > rte_mbuf_raw_free(stuct rte_mbuf *m) > { > if (rte_mbuf_refcnt_update(m, -1) =3D=3D 0) > __rte_mbuf_raw_free(m); > } Well, if you're going to do that, let's recognize that rte_mbuf_raw_free() = was misnamed: it doesn't free an mbuf, it returns an mbuf that's already free back to the= pool. So instead of "__rte_mbuf_raw_free", I'd call it "rte_mbuf_raw_release". Logically I like this solution, as I'm very uncomfortable with the idea tha= t a free mbuf might sometimes have refcnt set to one. On the other hand, if mbufs can oft= en be freed without touching refcnt, that could be a big win that might persuade me to = accept being uncomfortable. -don provan dprovan@bivio.net