From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0064.outbound.protection.outlook.com [104.47.1.64]) by dpdk.org (Postfix) with ESMTP id 268393772 for ; Tue, 26 Jul 2016 12:11:16 +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=28qcDNzTB3jJQWEzosoZJRVQ6PqTjYXXhfGQL2/b3fs=; b=CvFVnpxfgjSS7Ix+7vVHp/NCoDZDwRWVDW6qQ36kAkzChWBqhd+xLDqnRXzuz9zlx4OU9Ovehvi9IKCqkPmEeL93XAE6ZjHuZ/IxX4H6UqTXY1edC2f6LZTVyQAtCkoClwEHlj9ux8wukPAKaCgfRjWB2TGhpyJsK5Kqdbzjh/8= Received: from DB5PR04MB1605.eurprd04.prod.outlook.com (10.164.38.147) by DB5PR0401MB2056.eurprd04.prod.outlook.com (10.166.11.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.5; Tue, 26 Jul 2016 10:11:13 +0000 Received: from DB5PR04MB1605.eurprd04.prod.outlook.com ([10.164.38.147]) by DB5PR04MB1605.eurprd04.prod.outlook.com ([10.164.38.147]) with mapi id 15.01.0557.009; Tue, 26 Jul 2016 10:11:13 +0000 From: Hemant Agrawal To: David Hunt , "dev@dpdk.org" , "Thomas Monjalon" CC: "olivier.matz@6wind.com" , "viktorin@rehivetech.com" , "jerin.jacob@caviumnetworks.com" , "Shreyansh Jain" Thread-Topic: usages issue with external mempool Thread-Index: AdHnATWfB11qtF4jQMWZheRENVyKLA== Date: Tue, 26 Jul 2016 10:11:13 +0000 Message-ID: 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=hemant.agrawal@nxp.com; x-originating-ip: [192.88.169.1] x-ms-office365-filtering-correlation-id: 2be9a253-7a3f-4248-cd2b-08d3b53d2c97 x-microsoft-exchange-diagnostics: 1; DB5PR0401MB2056; 6:5CVvAV8KRQIJdBXz01kz6F5grdDuwOVTs2mpg4lpqyr2kc/CPgPdXOX4uIk0Q26mAApoQXuNERiYraubCoFh6i/Li4OVwMjfBabwUR5l5NqsYydg06N6RZBbv0wyjep949yupoeqG83c15ogXczKx1iqVyAKpqSHTGA7/BKiyEqwPWyHOIgnamIyMiQ3hx6rKsWV9dpN8tiGvhWVy1BJOV/4x36hTHg6Z+9uuGwofourav6xp5vVonz76r/jvwppyyMjgmj9K9ip9wZougcSaNQ9inPoVoSrVyEAElgn39yfTQEj9+qTV3FzABhMbQSGAboeDoTEgF/uAbHPVOEw9A==; 5:VMPUQhUjhr+KRCNotFpa+fAf8y05OgMJnhq5ZNnxYCZV805uesLNomdojwESr9LLtk5dWm7q5635aAVkojlJ0UiF27bOjDM5DzrMrQC/8gdHEDBNgTjpj+53FuGVdpMMbrFNISMe6WZYVMSblDhavg==; 24:UAhH9Dld5lkQpFHYZREgJeHbP03GkUjhgYkeXJ6WrKPaCuxq1ROoFLEiI809TX7G/PN4pQKNyAyqY6d+Aq3s7Spa1cj/SE2R2Ji2MVZroNI=; 7:HBOh7Rx6JochoX1OTd08OvyNwL0eGAmHHXUsKYXoy0+BjXToYynZP+9ugyy/c60w4oYAP3HUIhkVP7l3zRl45GbaqkQS2PKYHwOv5f9M82D09DgkOEzIuzrAy/4cs8AlGOrHMwOCJtsWnfXlu0rXvgxsGw6TRssSlgYhHjYXb6pSflgPC54kN0SLKpY3zlVvbM/tD8hi2IKjIrZhfrfwsfvHE6ImfGN5ULfzMzYo70ZXWgoww8LD3nRMRwnjd5Td x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR0401MB2056; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DB5PR0401MB2056; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0401MB2056; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(790700001)(9686002)(106356001)(2906002)(8676002)(87936001)(2900100001)(77096005)(15975445007)(68736007)(586003)(11100500001)(102836003)(5002640100001)(4326007)(3846002)(16236675004)(6116002)(122556002)(229853001)(66066001)(105586002)(76576001)(10400500002)(189998001)(92566002)(97736004)(2501003)(5001770100001)(101416001)(19625215002)(86362001)(54356999)(33656002)(50986999)(81166006)(7736002)(19580395003)(7696003)(9326002)(19300405004)(81156014)(8936002)(5003600100003)(7846002)(3660700001)(74316002)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR0401MB2056; H:DB5PR04MB1605.eurprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 10:11:13.4369 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0401MB2056 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] usages issue with external mempool 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: Tue, 26 Jul 2016 10:11:16 -0000 Hi, There was lengthy discussions w.r.t external mempool patches= . However, I am still finding usages issue with the agreed approach. The existing API to create packet mempool, "rte_pktmbuf_pool_create" does n= ot provide the option to change the object init iterator. This may be the r= eason that many applications (e.g. OVS) are using rte_mempool_create to cre= ate packet mempool with their own object iterator (e.g. ovs_rte_pktmbuf_in= it). e.g the existing usages are: dmp->mp =3D rte_mempool_create(mp_name, mp_size, MBUF_SIZE(mtu), MP_CACHE_SZ, sizeof(struct rte_pktmbuf_pool_private= ), rte_pktmbuf_pool_init, NULL, ovs_rte_pktmbuf_init, NULL, socket_id, 0); With the new API set for packet pool create, this need to be changed to: dmp->mp =3D rte_mempool_create_empty(mp_name, mp_size, MBUF_SIZE(mt= u), MP_CACHE_SZ, sizeof(struct rte_pktmbuf_pool_private= ), socket_id, 0); if (dmp->mp =3D=3D NULL) break; rte_errno =3D rte_mempool_set_ops_byname(dmp-= mp, RTE_MBUF_DEFAUL= T_MEMPOOL_OPS, NULL); if (rte_errno !=3D 0) { RTE_LOG(ERR, MBUF, "error sett= ing mempool handler\n"); return NULL; } rte_pktmbuf_pool_init(dmp->mp, NULL); ret =3D rte_mempool_populate_default(dmp->mp)= ; if (ret < 0) { rte_mempool_free(dmp->mp); rte_errno =3D -ret; return NULL; } rte_mempool_obj_iter(dmp->mp, ovs_rte_pktmbuf= _init, NULL); This is not a user friendly approach to ask for changing 1 API to 6 new API= s. Or, am I missing something? I think, we should do one of the following: 1. Enhance "rte_pktmbuf_pool_create" to optionally accept "rte_mempool_obj_= cb_t *obj_init, void *obj_init_arg" as inputs. If obj_init is not present, = default can be used. 2. Create a new wrapper API (e.g. e_pktmbuf_pool_create_new) with the abov= e said behavior e.g.: /* helper to create a mbuf pool */ struct rte_mempool * rte_pktmbuf_pool_create_new(const char *name, unsigned n, unsigned cache_size, uint16_t priv_size, uint16_t data_room_= size, rte_mempool_obj_cb_t *obj_init, void *obj_init_arg, int socket_id) 3. Let the existing rte_mempool_create accept flag as "MEMPOOL_F_HW_PKT_POO= L". Obviously, if this flag is set - all other flag values should be ignore= d. This was discussed earlier also. Please share your opinion. Regards, Hemant