From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50074.outbound.protection.outlook.com [40.107.5.74]) by dpdk.org (Postfix) with ESMTP id CFBDB28F3 for ; Thu, 8 Jun 2017 06:34:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BhlYv+0E+SmsF0F+VmMHMu5gTVwdo4/2EjhkgqbjApE=; b=CAB97tFudZL7lkFaW7oJ9o9IUg+ZymEqEhXzhgG/D+nTnj1WVmfSyOPIbhF7e920Ni0sY9ZWNRs56eoQ+WtTut4mt3AuCtLOKDpT2GjFlIgG2fdPZtdYQEVmgm/SMO5oiEEbtt2p5LzgI21ANAYNrhmuMjJNG7htmRpUEvmjI0E= Received: from VI1PR0401MB2464.eurprd04.prod.outlook.com (10.168.64.147) by VI1PR0401MB2463.eurprd04.prod.outlook.com (10.168.64.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.10; Thu, 8 Jun 2017 04:34:53 +0000 Received: from VI1PR0401MB2464.eurprd04.prod.outlook.com ([fe80::f898:72f7:3bab:83c3]) by VI1PR0401MB2464.eurprd04.prod.outlook.com ([fe80::f898:72f7:3bab:83c3%18]) with mapi id 15.01.1143.019; Thu, 8 Jun 2017 04:34:52 +0000 From: Shreyansh Jain To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: "dev@dpdk.org" , Jan Blunck Thread-Topic: [PATCH v2 01/11] bus: add bus iterator to find a particular bus Thread-Index: AQHS35HdynGYVwkK+0+fzdvu6E+X4aIZj0xA Date: Thu, 8 Jun 2017 04:34:50 +0000 Deferred-Delivery: Wed, 7 Jun 2017 16:09:13 +0000 Message-ID: References: <33c95f6a-82b4-6557-7011-f210f34cbc88@nxp.com> <20170607132742.GP18840@bidouze.vm.6wind.com> In-Reply-To: <20170607132742.GP18840@bidouze.vm.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: 6wind.com; dkim=none (message not signed) header.d=none;6wind.com; dmarc=none action=none header.from=nxp.com; x-originating-ip: [192.88.169.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0401MB2463; 7:RZtuwA1Mg2sgxYp4ei/Ox4ml/PXreVlew0o95ZwcTQzgHBtJp1DdD7Pf8x8EL72jJrPYGgE1MtSLSfF914PUMP6oitAVEF/Vu3mC4baKmOxEVUFQ0AWxkCvtW6zFZfHhiaY4cAjLvmMV/AGURAS2HM5XsLhk6iqLCkCkwEdnewUHb5OsnFMie6Op/UxR9BK7xiCdsJ4wDyGfC0fGRwjNOZrfcb3LtJh1OT7P9lJABA9OshSrG4B0dsnuiXQ3d+etgbSCL9BNqrbguU4weO0KvB+8qzpXPx9mFD9p9K9uwJomcuVhgY8Ku9aBbyRUrkJtx9wSXjTykURzzZQ2yTJuIQ== x-ms-traffictypediagnostic: VI1PR0401MB2463: x-ms-office365-filtering-correlation-id: 5f14c01e-ff70-46fc-3ad2-08d4ae27b4f9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR0401MB2463; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(185117386973197); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0401MB2463; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0401MB2463; x-forefront-prvs: 0332AACBC3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39450400003)(39860400002)(39410400002)(39850400002)(39840400002)(13464003)(24454002)(377454003)(99286003)(9686003)(53936002)(14454004)(6436002)(6246003)(25786009)(3280700002)(53546009)(2950100002)(38730400002)(229853002)(5250100002)(55016002)(3660700001)(110136004)(6506006)(4326008)(6916009)(74316002)(7736002)(305945005)(54356999)(478600001)(7696004)(33656002)(189998001)(54906002)(50986999)(76176999)(5660300001)(561944003)(81166006)(2900100001)(86362001)(8676002)(66066001)(3846002)(102836003)(8936002)(93886004)(6116002)(37363001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0401MB2463; H:VI1PR0401MB2464.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 04:34:52.7866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2463 Subject: Re: [dpdk-dev] [PATCH v2 01/11] bus: add bus iterator to find a particular bus 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: Thu, 08 Jun 2017 04:34:55 -0000 Hello Ga=EBtan, > -----Original Message----- > From: Ga=EBtan Rivet [mailto:gaetan.rivet@6wind.com] > Sent: Wednesday, June 07, 2017 6:58 PM > To: Shreyansh Jain > Cc: dev@dpdk.org; Jan Blunck > Subject: Re: [PATCH v2 01/11] bus: add bus iterator to find a particular = bus >=20 > On Wed, Jun 07, 2017 at 12:36:53PM +0530, Shreyansh Jain wrote: > > Hello Gaetan, > > > > On Wednesday 31 May 2017 06:47 PM, Gaetan Rivet wrote: > > >From: Jan Blunck > > > > > >Signed-off-by: Jan Blunck > > >Signed-off-by: Gaetan Rivet > > >--- > > > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 + > > > lib/librte_eal/common/eal_common_bus.c | 13 ++++++++++ > > > lib/librte_eal/common/include/rte_bus.h | 32 > +++++++++++++++++++++++++ > > > lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 + > > > 4 files changed, 47 insertions(+) > > > > > >diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map > b/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > >index 2e48a73..ed09ab2 100644 > > >--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > >+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map > > >@@ -162,6 +162,7 @@ DPDK_17.02 { > > > DPDK_17.05 { > > > global: > > >+ rte_bus_find; > > > rte_cpu_is_supported; > > > rte_log_dump; > > > rte_log_register; > > >diff --git a/lib/librte_eal/common/eal_common_bus.c > b/lib/librte_eal/common/eal_common_bus.c > > >index 8f9baf8..68f70d0 100644 > > >--- a/lib/librte_eal/common/eal_common_bus.c > > >+++ b/lib/librte_eal/common/eal_common_bus.c > > >@@ -145,3 +145,16 @@ rte_bus_dump(FILE *f) > > > } > > > } > > > } > > >+ > > >+struct rte_bus * > > >+rte_bus_find(rte_bus_match_t match, const void *data) > > >+{ > > >+ struct rte_bus *bus =3D NULL; > > >+ > > >+ TAILQ_FOREACH(bus, &rte_bus_list, next) { > > >+ if (match(bus, data)) > > >+ break; > > >+ } > > >+ > > >+ return bus; > > >+} > > >diff --git a/lib/librte_eal/common/include/rte_bus.h > b/lib/librte_eal/common/include/rte_bus.h > > >index 7c36969..006feca 100644 > > >--- a/lib/librte_eal/common/include/rte_bus.h > > >+++ b/lib/librte_eal/common/include/rte_bus.h > > >@@ -141,6 +141,38 @@ int rte_bus_probe(void); > > > void rte_bus_dump(FILE *f); > > > /** > > >+ * Bus match function. > > >+ * > > >+ * @param bus > > >+ * bus under test. > > >+ * > > >+ * @param data > > >+ * data matched > > >+ * > > >+ * @return > > >+ * 0 if the bus does not match. > > >+ * !0 if the bus matches. > > > > One of the common match function implementation could be simply to matc= h > > a string. strcmp itself returns '0' for a successful match. > > On the same lines, should this function return value be reversed? > > - > > 0 if match > > !0 if not a match > > - > > That way, people would not have to change either the way strcmp works, > > for example, or the way various APIs expect '0' as success. > > > > same for rte_device_match_t as well. (in next patch) > > >=20 > It was actually a point I hesitated a little before submitting this > version. >=20 > The logic behind strcmp is that you can express three states: greater > than, equal, lower than, thus having total order within the string set. >=20 > Here, buses are not ordered (logically). Having a bus lower or greater > than some arbitrary data does not mean much. I agree about the match() fn - but, this is not what I meant.=20 My point was that ideally for implementation of callbacks, applications would more often use the strcmp function (matching name of the bus) than the match() callback. Further, this semantic is being followed by other DPDK APIs as well - so, my intent was to make this also inline with those. >=20 > Anyway, this was my reasoning for following Jan's proposal on this, but > I'm not against changing this API. Maybe having to possibility to > express total order could be useful eventually. I don't have a strong > opinion on this so unless someone shouts about it, I will follow your > remark. Thank you! >=20 <...snip...>