From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <hemant.agrawal@nxp.com>
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 <dev@dpdk.org>; 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 <hemant.agrawal@nxp.com>
To: David Hunt <david.hunt@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Thomas
Monjalon" <thomas.monjalon@6wind.com>
CC: "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"viktorin@rehivetech.com" <viktorin@rehivetech.com>,
"jerin.jacob@caviumnetworks.com" <jerin.jacob@caviumnetworks.com>, "Shreyansh
Jain" <shreyansh.jain@nxp.com>
Thread-Topic: usages issue with external mempool
Thread-Index: AdHnATWfB11qtF4jQMWZheRENVyKLA==
Date: Tue, 26 Jul 2016 10:11:13 +0000
Message-ID: <DB5PR04MB1605210D71D8CA61C01C78B6890E0@DB5PR04MB1605.eurprd04.prod.outlook.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=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: <DB5PR0401MB20568E000212A69ADEA15996890E0@DB5PR0401MB2056.eurprd04.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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