Message ID | 1516281992-6873-3-git-send-email-hemant.agrawal@nxp.com (mailing list archive) |
---|---|
State | Superseded, archived |
Delegated to: | Thomas Monjalon |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 95EC81B2DA; Thu, 18 Jan 2018 14:27:57 +0100 (CET) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0040.outbound.protection.outlook.com [104.47.41.40]) by dpdk.org (Postfix) with ESMTP id 5703F1B1E1 for <dev@dpdk.org>; Thu, 18 Jan 2018 14:27:53 +0100 (CET) Received: from CY1PR03CA0017.namprd03.prod.outlook.com (10.174.128.27) by CY1PR03MB2363.namprd03.prod.outlook.com (10.166.207.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Thu, 18 Jan 2018 13:27:52 +0000 Received: from BN1AFFO11FD023.protection.gbl (2a01:111:f400:7c10::121) by CY1PR03CA0017.outlook.office365.com (2603:10b6:600::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.407.7 via Frontend Transport; Thu, 18 Jan 2018 13:27:52 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; NXP1.onmicrosoft.com; dkim=none (message not signed) header.d=none;NXP1.onmicrosoft.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BN1AFFO11FD023.mail.protection.outlook.com (10.58.52.83) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.345.12 via Frontend Transport; Thu, 18 Jan 2018 13:27:48 +0000 Received: from bf-netperf1.ap.freescale.net (bf-netperf1.ap.freescale.net [10.232.134.28]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id w0IDRdIl028023; Thu, 18 Jan 2018 06:27:46 -0700 From: Hemant Agrawal <hemant.agrawal@nxp.com> To: <dev@dpdk.org> CC: <jerin.jacob@caviumnetworks.com>, <olivier.matz@6wind.com>, <santosh.shukla@caviumnetworks.com>, Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> Date: Thu, 18 Jan 2018 18:56:27 +0530 Message-ID: <1516281992-6873-3-git-send-email-hemant.agrawal@nxp.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1516281992-6873-1-git-send-email-hemant.agrawal@nxp.com> References: <1515996674-26338-1-git-send-email-hemant.agrawal@nxp.com> <1516281992-6873-1-git-send-email-hemant.agrawal@nxp.com> X-EOPAttributedMessage: 0 X-Matching-Connectors: 131607556712687398; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(7966004)(39380400002)(346002)(376002)(39860400002)(396003)(2980300002)(1110001)(1109001)(339900001)(189003)(199004)(4326008)(305945005)(104016004)(51416003)(2950100002)(47776003)(6916009)(77096007)(8676002)(105606002)(2906002)(356003)(5660300001)(16586007)(68736007)(2351001)(81156014)(81166006)(50466002)(76176011)(508600001)(54906003)(6666003)(48376002)(316002)(50226002)(106466001)(8936002)(296002)(36756003)(85426001)(86362001)(26005)(53936002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2363; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD023; 1:WJpY5fqxOkPV+DBo3kGlmD8L4PhgACZAqvJLBADvFrsiYscuTTUYyiRySotf4NOPjkJUgqHeHbPbkKISP1TTMj5ERy3QW7ZHk6+xmLg/xXSRTo6OVmuOT8wDZ2QZg494 MIME-Version: 1.0 Content-Type: text/plain X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54b9504d-0730-476e-e726-08d55e774614 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(5600026)(4604075)(2017052603307); SRVR:CY1PR03MB2363; X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2363; 3:/KPzWfA5GUR5F/hyy8oChDKHXxOR8AdFskRLrJjXNf3OYqoulymjX+o/HHjZljjKZGHe2OOaVfiN6YQpRe892TV4ann+DvtM2sRzQZP6wkmsx6Ijt7I7bWhzbtHWhDIrbJmkZDflwI8eZITsqi+gezg7IZlWVZxNOFyCjRdxiGET8GEi+J4dUiipF/A2JlXUTE0XMLRQ/UWU4tUJVW/YqFfaD+cX+F2Zlc3KbSNVtnWZ4iNsCnCZeF7muQhD6R48cFuX03AKa7gFQXObAvp3rmYVL3NHVerJG13v+oLvuOPhltJG1tattmbVpKnGMrayPxuEae9LWwBuqVizyGNDK21u6hdfy7g5gjtgt3erAXw=; 25:WFLlG0uWc99LsqgKZ01zYz2Ts9sqVpV3FiZAPROr/f+oM0gE+Y+Z977bX3BK5NVM4na582Ks239tPArKTTaF/aFvgvSHjI+0+bP56/6uavqpWusZcL/bqWt8vLzYZ/ImcfqPBys/MGuJX0uFL89RJsNDZZQv4ugSgMS1gkVmgTHrgxHz9+tqs9vbq7C2ph3z21hucVR6zo9uN8e3Zjcupvf2GTx6VYNREwQ41z/dpUJouOoYqanQw5WJuxK8b9ApP6IP0N6wPGQgOsVCva0/UalRAsIliG45Bn/OIuzIY7eYMIJfFx6zPLkeZCZwM4a6rEY7laHCqN1zvHilkf3vLw== X-MS-TrafficTypeDiagnostic: CY1PR03MB2363: X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2363; 31:+qOZyal4W3LBxLLcxYVgjAdhzX1x9ErZ7lpz7n7u0DfSMftEx0qN+yeE1lj6zwIhDZaXyFlPXDw/KaUx2XwcR8L3d6WwxsvqTZu3zFFAs6BsUJ22M/xYPCsDEQjdHNrUSw8JA9Ew6ZmjHK8ZUDfSoDQujjf8DtS+c0zf+kBLt77TUvN2NG4O5S5eGf41yGLhtPkXWVY6Kd5U0q3Jv9VAntHo62IoRg+97LGmVCRAe1k=; 4:RREyP/H95DZ3wYdthqDuiK/TWNTzVe/aGhp2nF8FfwVSNxM5mXTxz+m1NObhqvlBpL4Nbh7VRwxgt9s3vBxzFVWj+OEPyxOV3TSdSsZus1Wfbds7tBtyVkdMUsZolP/AAfDVkYD/r50XXplaZz00AWc29hFvgCjCWKgjky9WDu6XOq6Jim5HVzVn679AWJUCCARmC74burSh4cAyxBdPgQiuEDAArX7pHL95ToS1ndOKQRu4mkIoTltXDLacTTIOufO56AzHKD+9AuGaBhOGJEti1l2bxnaSQVBXD+zSLBmW9cARlPpt4JeM5uSaiSMs X-Microsoft-Antispam-PRVS: <CY1PR03MB2363A96884C6109070F9CED889E80@CY1PR03MB2363.namprd03.prod.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:(185117386973197); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6095135)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(944501161)(3002001)(10201501046)(6055026)(6096035)(20161123563025)(20161123559100)(20161123556025)(20161123565025)(20161123561025)(201703131430075)(201703131520075)(201703131441075)(201703131448075)(201703131433075)(201708071742011); SRVR:CY1PR03MB2363; BCL:0; PCL:0; RULEID:(100000803101)(100110400095)(400006); SRVR:CY1PR03MB2363; X-Forefront-PRVS: 05568D1FF7 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR03MB2363; 23:dkM/60l+ONnPfu/GX2A/ksHzqtFwSRg5M7u96k/i1?= jSQ2aIVpDHTCp7uZW5RfP4H8TFJpLYcdcZRWCuJPVOW8JLr7SzO62+wcrQetdE9AD8dmNHrN55MHGSlk0DScDOTY5M+4l7a+MhBP9oHQvtKjjxoQdyeHaz6JB2RwPj6RsTygke0sQzzsj9uzm/Dz9qflAeTPx4VlS8nS7LOnzryQBVOw/obyujwO/WoE2zrNp0NAUDCmgEaYRtj7R0u+6NjSkbqsGYDIoJw42qmNv4YQ6R1bXabSZU1b7c5MPp2pECLOjOSvdf9keS2f7LWeaLz7Fn2cPAxTWoJoG4bRdcJYUD4B9JGtTMXJDv5nqkMCQcE1BQ/i2LD3H2XmWK9+BHqm4de/zNUbkK6+Cjs2UTIj9ff253NbO4TJxEdn/F6h3FdTCeP1TNegZx/BYdUEx/vPCcR4nobZ3xeX5SksBMP4CgI5GhazEmTd/5jx9pXHPdP7bfpxP51OI/3Q9sH0xTEPDYcam3PecNdwXNAJozflkFvs7dt8lJ4R1U6DjGOSxRawFF27wusn8XmZiMWJodYJTom2gIMTPeHDN4HEOYP+XjxaWnOEaYgprqgyMONeHRHFxZDNKmUSoHqy/C9v5WXyhH2pUZI3VS0/RjkCWfGIZlEOP6YfElg2g7a5Dk/bKZ7HyUHursF1nsUn4UZlpKmaaXEH723gozLd33CLV4FECMfD58FtREWHX2ih9NaTM1xl7rnlsXdgkNaRllEcKTp0Kl/1HElrLsd+L3qB68Lr0n1ivhWoLIuadlEmy/5soAtM5icI0d2/M7M/IH1hBdbQWWp8usmcPFxXSooXFnUcqTofcAyC1/V/t3feAY+J3enRSm4MjDLGNJPY6EAQ87NJOe/E26a6i3hilzXHomnGSx5Cnx1lCRr5qhqoUryqxPngKowLiV0phhl/2GA3xvAkIRU0u91DsfFi6ylfPhPcbqy8RHewWY2Z+87hgltZVo9B+EvJOTa0hWegR191MF+U9ToFpG1sE/6djIJJl6PrxMFfNu+ZmGwY+RkUazIBaHPFIRTc4fFOmMz+gb0RUihlvuUldBl3YcXU6VDy8RebQ== X-Microsoft-Exchange-Diagnostics: 1; CY1PR03MB2363; 6:hv2TxbSBhZfqH3ZydQ0J71nkTs5l623cUAqmh57O84LH4jmN6JOJWkcxMjPv+S2xHqOUXVXSWJyi0seUOMv2x/VA3OusfgOv7FamyYjrFFAgR5zD/2hi9y0Lnymc+V4tteHcoKFIPCl8SyJVad8Ct1Lts7lfXEtG+lmn+/xnHiEmB464TsHMv7Ro9rSbgqlstRQy1rf2T5qxjrUeaMpMAtZ/xd8XnIp7hz6Oc74Z2MXHNof40u6XrS4gNLe0tRDTItAlnAdBIFGKPPya+T4o5UVpHl98fhoeaEum5HGvHiqrevzPDBdj3n+YdSAsIbx1ySKyPgAQiOKZwyK0Sg4HmtQ/Wi9k65aoUiTqIkmiyXE=; 5:yWNvp38CddPXMd+zmZ5t54P251M96dTAuAvvH3mulAiFZiQSqlrh55pZbIajAbDc12/vBBmHcyrwMUlyXInVr1vLynROh9RUKrgypS+3iNQv3N8jXkEAPE6uV5+EB8Xy1xqyIbL1AdHa0YrwQXhVR3xvQ7RtZSmuq+qrGERrWgM=; 24:ZF7sbRI31Se4pJ20QcLwimSF2vBaMSriy+CcfRkd2p9g1bZJUlJWWCPM68WyKjMnXChQ6uZm0MK0dfWNm3x1DycmP39SEddrGD1/s8LgPAU=; 7:xnXhGepuPLj93p0B+CfjU4hG58E5+epnj+fTtYoGoizpN41dSqzbGkWl5BQwtKapHUxUkHxlsMmCk93HoTQ96tliMuNJSDk/5G1c8MWxegtEsPw+AsKKIKLQ9Vo6Mfz15IBZCc1k5s25QTwKeuvxe0FTl5hLup2yBdJkd+D4XYvPXH9NlDD+qo5Mks08C0rCDDHgfIbTGPwtz4oMm7VhodMAVyjZk+/kfwnPi6SxaKAsUVrX2UBD+iy9MHPLyNWF SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2018 13:27:48.9918 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 54b9504d-0730-476e-e726-08d55e774614 X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2363 Subject: [dpdk-dev] [PATCH v3 2/7] eal: add API to set user default mbuf mempool ops X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://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: <https://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Checks
Context | Check | Description |
---|---|---|
ci/checkpatch | success | coding style OK |
ci/Intel-compilation | success | Compilation OK |
Commit Message
Hemant Agrawal
Jan. 18, 2018, 1:26 p.m. UTC
Add new API to set the user defined mbuf mempool ops name i.e. set the provided ops name to `internal_config.mbuf_pool_ops_name`. Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com> --- lib/librte_eal/bsdapp/eal/eal.c | 6 ++++++ lib/librte_eal/common/include/rte_eal.h | 9 +++++++++ lib/librte_eal/linuxapp/eal/eal.c | 6 ++++++ lib/librte_eal/rte_eal_version.map | 1 + 4 files changed, 22 insertions(+)
Comments
On Thu, Jan 18, 2018 at 06:56:27PM +0530, Hemant Agrawal wrote: > Add new API to set the user defined mbuf mempool ops name > i.e. set the provided ops name to `internal_config.mbuf_pool_ops_name`. > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com> > --- > lib/librte_eal/bsdapp/eal/eal.c | 6 ++++++ > lib/librte_eal/common/include/rte_eal.h | 9 +++++++++ > lib/librte_eal/linuxapp/eal/eal.c | 6 ++++++ > lib/librte_eal/rte_eal_version.map | 1 + > 4 files changed, 22 insertions(+) > > diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c > index c602d02..64f010a 100644 > --- a/lib/librte_eal/bsdapp/eal/eal.c > +++ b/lib/librte_eal/bsdapp/eal/eal.c > @@ -117,6 +117,12 @@ rte_eal_mbuf_default_mempool_ops(void) > return internal_config.user_mbuf_pool_ops_name; > } > > +void > +rte_eal_set_mbuf_user_mempool_ops(const char *ops_name) > +{ > + internal_config.user_mbuf_pool_ops_name = ops_name; > +} > + I think we should only have the "set" API in mbuf lib. What do you think about what I suggested in http://dpdk.org/ml/archives/dev/2018-January/087419.html ? """ The proper way is maybe to keep the parsing in eal, and at librte_mbuf initialization, query the eal library to get the user pool if any. After that, all will be managed inside librte_mbuf. So the eal lib will only do the argument parsing. """ In that case, this patch could be dropped. Please refer to my comment in patch 3 to see what other modifications would be needed.
Hi Olivier, On 1/19/2018 3:31 PM, Olivier Matz wrote: > On Thu, Jan 18, 2018 at 06:56:27PM +0530, Hemant Agrawal wrote: >> Add new API to set the user defined mbuf mempool ops name >> i.e. set the provided ops name to `internal_config.mbuf_pool_ops_name`. >> >> Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> >> Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com> >> --- >> lib/librte_eal/bsdapp/eal/eal.c | 6 ++++++ >> lib/librte_eal/common/include/rte_eal.h | 9 +++++++++ >> lib/librte_eal/linuxapp/eal/eal.c | 6 ++++++ >> lib/librte_eal/rte_eal_version.map | 1 + >> 4 files changed, 22 insertions(+) >> >> diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c >> index c602d02..64f010a 100644 >> --- a/lib/librte_eal/bsdapp/eal/eal.c >> +++ b/lib/librte_eal/bsdapp/eal/eal.c >> @@ -117,6 +117,12 @@ rte_eal_mbuf_default_mempool_ops(void) >> return internal_config.user_mbuf_pool_ops_name; >> } >> >> +void >> +rte_eal_set_mbuf_user_mempool_ops(const char *ops_name) >> +{ >> + internal_config.user_mbuf_pool_ops_name = ops_name; >> +} >> + > > I think we should only have the "set" API in mbuf lib. > > What do you think about what I suggested in > http://dpdk.org/ml/archives/dev/2018-January/087419.html ? > > """ > The proper way is maybe to keep the parsing in eal, and at librte_mbuf > initialization, query the eal library to get the user pool if any. > After that, all will be managed inside librte_mbuf. So the eal lib will > only do the argument parsing. > """ > Will you please help me in understanding, how should I do it? 1. The is no standard librte_mbuf initialization routine. RTE_INIT will not work, as it will be executed before eal_init. dlopen is for shared lib only. Is there any other method? 2. If I call it on the very first call of rte_mbuf_user_mempool_ops_name or rte_mbuf_set_user_mempool_ops_name, I will be checking against NULL. It can be NULL always. So, no real meaning of maintaining it in librte_mbuf as well. Yes, I can maintain a flag to know, If I have synced with eal parse before. But that is not sounding to me clean. > In that case, this patch could be dropped. Please refer to my comment > in patch 3 to see what other modifications would be needed. >
On Fri, Jan 19, 2018 at 06:01:55PM +0530, Hemant Agrawal wrote: > Hi Olivier, > > On 1/19/2018 3:31 PM, Olivier Matz wrote: > > On Thu, Jan 18, 2018 at 06:56:27PM +0530, Hemant Agrawal wrote: > > > Add new API to set the user defined mbuf mempool ops name > > > i.e. set the provided ops name to `internal_config.mbuf_pool_ops_name`. > > > > > > Signed-off-by: Pavan Nikhilesh <pbhagavatula@caviumnetworks.com> > > > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com> > > > --- > > > lib/librte_eal/bsdapp/eal/eal.c | 6 ++++++ > > > lib/librte_eal/common/include/rte_eal.h | 9 +++++++++ > > > lib/librte_eal/linuxapp/eal/eal.c | 6 ++++++ > > > lib/librte_eal/rte_eal_version.map | 1 + > > > 4 files changed, 22 insertions(+) > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c > > > index c602d02..64f010a 100644 > > > --- a/lib/librte_eal/bsdapp/eal/eal.c > > > +++ b/lib/librte_eal/bsdapp/eal/eal.c > > > @@ -117,6 +117,12 @@ rte_eal_mbuf_default_mempool_ops(void) > > > return internal_config.user_mbuf_pool_ops_name; > > > } > > > > > > +void > > > +rte_eal_set_mbuf_user_mempool_ops(const char *ops_name) > > > +{ > > > + internal_config.user_mbuf_pool_ops_name = ops_name; > > > +} > > > + > > > > I think we should only have the "set" API in mbuf lib. > > > > What do you think about what I suggested in > > http://dpdk.org/ml/archives/dev/2018-January/087419.html ? > > > > """ > > The proper way is maybe to keep the parsing in eal, and at librte_mbuf > > initialization, query the eal library to get the user pool if any. > > After that, all will be managed inside librte_mbuf. So the eal lib will > > only do the argument parsing. > > """ > > > > Will you please help me in understanding, how should I do it? > > 1. The is no standard librte_mbuf initialization routine. RTE_INIT will not > work, as it will be executed before eal_init. dlopen is for shared lib only. > Is there any other method? > > 2. If I call it on the very first call of rte_mbuf_user_mempool_ops_name or > rte_mbuf_set_user_mempool_ops_name, I will be checking against NULL. It can > be NULL always. So, no real meaning of maintaining it in librte_mbuf as > well. > Yes, I can maintain a flag to know, If I have synced with eal parse before. > But that is not sounding to me clean. My initial idea was to do it at init, but I came to the same conclusion than yours, it is not possible. Can you take a look to the comments of patch 3/7 and let me know if the proposition fits your needs?
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c index c602d02..64f010a 100644 --- a/lib/librte_eal/bsdapp/eal/eal.c +++ b/lib/librte_eal/bsdapp/eal/eal.c @@ -117,6 +117,12 @@ rte_eal_mbuf_default_mempool_ops(void) return internal_config.user_mbuf_pool_ops_name; } +void +rte_eal_set_mbuf_user_mempool_ops(const char *ops_name) +{ + internal_config.user_mbuf_pool_ops_name = ops_name; +} + /* Return a pointer to the configuration structure */ struct rte_config * rte_eal_get_configuration(void) diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h index 2aba2c8..7645b34 100644 --- a/lib/librte_eal/common/include/rte_eal.h +++ b/lib/librte_eal/common/include/rte_eal.h @@ -307,6 +307,15 @@ enum rte_iova_mode rte_eal_iova_mode(void); const char * rte_eal_mbuf_default_mempool_ops(void); +/** + * Set user pool ops name for mbuf + * + * @param ops_name + * mempool ops name that is to be set as user defined. + */ +void +rte_eal_set_mbuf_user_mempool_ops(const char *ops_name); + #ifdef __cplusplus } #endif diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c index e8c7100..46b2bb3 100644 --- a/lib/librte_eal/linuxapp/eal/eal.c +++ b/lib/librte_eal/linuxapp/eal/eal.c @@ -127,6 +127,12 @@ rte_eal_mbuf_default_mempool_ops(void) return internal_config.user_mbuf_pool_ops_name; } +void +rte_eal_set_mbuf_user_mempool_ops(const char *ops_name) +{ + internal_config.user_mbuf_pool_ops_name = ops_name; +} + /* Return a pointer to the configuration structure */ struct rte_config * rte_eal_get_configuration(void) diff --git a/lib/librte_eal/rte_eal_version.map b/lib/librte_eal/rte_eal_version.map index 7088b72..3529885 100644 --- a/lib/librte_eal/rte_eal_version.map +++ b/lib/librte_eal/rte_eal_version.map @@ -203,6 +203,7 @@ DPDK_17.11 { DPDK_18.02 { global: + rte_eal_set_mbuf_user_mempool_ops; rte_hypervisor_get; rte_hypervisor_get_name; rte_vfio_clear_group;