From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70058.outbound.protection.outlook.com [40.107.7.58]) by dpdk.org (Postfix) with ESMTP id 7468E5F36 for ; Mon, 3 Dec 2018 00:28:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QOXGgfY4PR8uKz4bAqp7/3qa4jTNYzqrhEQh8RUOhUI=; b=DI/AttuFFjAe5qQD/f8QZISFMpw21S85GaNUGmBQ9C0AZs3JFXkNOPFd4Ig7bzwNMs9gWM1jd2oRSYm5tegZQZ2/C+vjnW7tND5CtOdgHafVPcdzblq6eZqNonoakyx3iDHfMmMBksPNQo+C75fxe8PTdzR7j1/66MWaU22klG0= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4089.eurprd05.prod.outlook.com (52.134.68.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.18; Sun, 2 Dec 2018 23:28:51 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::dcbc:4578:3018:50f3]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::dcbc:4578:3018:50f3%5]) with mapi id 15.20.1382.020; Sun, 2 Dec 2018 23:28:51 +0000 From: Yongseok Koh To: Shahaf Shuler CC: Anatoly Burakov , "dev@dpdk.org" , Thomas Monjalon , "shreyansh.jain@nxp.com" Thread-Topic: [PATCH 0/4] Allow using external memory without malloc Thread-Index: AQHUh+o+UL0xxxq8xkaRCgNf8gc/VqVq9YKAgAEoOoA= Date: Sun, 2 Dec 2018 23:28:51 +0000 Message-ID: <7F52E2C1-4552-48E7-9AFA-BEAF4D8E45D7@mellanox.com> References: In-Reply-To: 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=yskoh@mellanox.com; x-originating-ip: [69.181.245.183] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR0502MB4089; 6:G3x6F0VsPMhbe26CoAy94H2fHTPjgpLsYBcSb+0IFj3is++yvjn3/KDKH4px5xDUTJSD04si8EdXjTQl8CxhRD27A9Ug5GbEzZ5o7DyXq24EMymenlu6fMGSbJix8fy7M0yS2Pr5SxhjtQSZQj/fnCSy6336Il0gPX7gETybutjoGwemalRgC0fG3y2eM9WZH+srY7JQuRv9HXx6vdaL3zXz3wyANeDh63102eal+qYbSn89MoVh9JATYVEYcr9mrZl5DKMY+a1coWOWuQj72g18ZzshTACzg0YraTl3rcpUSA4jKlZDiDIfP5PWg0O8mQb5y3jkh7p0IZ4gZO+L2fCTv+HYtDgCEbeBEpwWGkymBJp0SM0FAPzhQTvbFFY+XJwcIjl1VU5PHGyqtAA5KXNvnPzP+CFeX4nO8WEdoMKOhYHsNTdBaihIIM6wWsRtb0MnDPmocFieTyehBE/gwQ==; 5:0g4kxs1ZwKukZiCZrbWbbg03GSZIckbOkLzVLBN7xl8oxp/HblWTXC6z1hFCZgXeL5wNdT0ZXnljIfMvPTafFDLyPeaffx92UXmz1gI02eUskcPlQAxoqx420u5JOvFdM6R9OSaPX7c5Qg7ly2YuB6CYCzrFWDHiRN5eF+VyL6Q=; 7:UNFNi6epKrPQt8jtTu3nHJMIm+YZie6VwGXpGWduBWJH6sn0uTpj+mb40stzVH5nXK6p2yXczZDJyXCAgOfu5a15iGiGOUSxglBpMQhLM8yYC0I65KCSg3mMezBJXDiFDHS4PEhyZB6ZgwY18i5H8A== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8e9d3bfd-f9ff-461b-66c1-08d658adeb43 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB3PR0502MB4089; x-ms-traffictypediagnostic: DB3PR0502MB4089: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231455)(999002)(944501493)(52105112)(3002001)(93006095)(93001095)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB3PR0502MB4089; BCL:0; PCL:0; RULEID:; SRVR:DB3PR0502MB4089; x-forefront-prvs: 087474FBFA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(136003)(376002)(189003)(199004)(69234005)(476003)(11346002)(446003)(86362001)(6436002)(68736007)(97736004)(99286004)(966005)(478600001)(76176011)(186003)(486006)(2616005)(71200400001)(14454004)(71190400001)(26005)(6506007)(53546011)(83716004)(102836004)(25786009)(2906002)(5660300001)(7736002)(229853002)(6636002)(305945005)(82746002)(6486002)(33656002)(3846002)(6116002)(45080400002)(106356001)(105586002)(316002)(36756003)(54906003)(37006003)(6306002)(6246003)(8676002)(6862004)(8936002)(66066001)(81156014)(81166006)(6512007)(4326008)(53936002)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4089; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: My4QLaGLn4oSGFSZF3cEkWRxBB95ol947vC8b7qcvMteiagXKdQuGRJjGvKeYIegxZqXvLclXugLUvrLYdXSGPLjfnBHbbYQxfTzxVG+rzd+OfBtbIknF8C3sTVcsIrxOYCwRyr3RFfRBJ4zN/5NvxmWZbN+tZGSYpp2QfudVIGKqP4sQPxLwt8WVFb7ssrbeUGLac+GObPyyhVusWSzbtC/YqjUqfAASJj54F8L+R3NP7JCK/z/Z1ADk8yuAKyxTt4iZBbYaC2SpWkEDCsj28+BZfkAcp+5RAixqrGcCJJHg5bbrd5hdbeMPfQ7f6uHfKWSfOWyUkKNGXP7TbEKlS6bM1/7PL8py7o1vvfF/F8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <7464765C40EE954DBCBFCA0466E0412B@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e9d3bfd-f9ff-461b-66c1-08d658adeb43 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2018 23:28:51.7802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4089 Subject: Re: [dpdk-dev] [PATCH 0/4] Allow using external memory without malloc 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: Sun, 02 Dec 2018 23:28:55 -0000 > On Dec 1, 2018, at 9:48 PM, Shahaf Shuler wrote: >=20 > Hi Anatoly,=20 >=20 > Thursday, November 29, 2018 3:49 PM, Anatoly Burakov: >> Subject: [PATCH 0/4] Allow using external memory without malloc >>=20 >> Currently, the only way to use externally allocated memory is through >> rte_malloc API's. While this is fine for a lot of use cases, it may not = be suitable >> for certain other use cases like manual memory management, etc. >>=20 >> This patchset adds another API to register memory segments with DPDK (so >> that API's like ``rte_mem_virt2memseg`` could be relied on by PMD's and >> such), but not create a malloc heap out of them. >>=20 >> Aside from the obvious (not adding memory to a heap), the other major >> difference between this API and the ``rte_malloc_heap_*`` external memor= y >> functions is the fact that no DMA mapping is performed automatically. >>=20 >> This really draws a line in the sand, and there are now two ways of doin= g >> things - do everything automatically (using the ``rte_malloc_heap_*`` AP= I's), >> or do everything manually (``rte_extmem_*`` and future DMA mapping API >> [1] that would replace ``rte_vfio_dma_map``). This way, the consistency = of >> API is kept, and flexibility is also allowed. >>=20 >=20 > As you know I like the idea. > One question though, do you see a use case for application to have extern= ally allocated memory which needs to be registered to the DPDK subsystem ho= wever not being used for DMA? > My only guess would be so helper libraries which requires the memory allo= cation from user (however it doesn't seems like a good API).=20 >=20 > If no use case, maybe it is better to merge between the two (rte_extmem_*= and rte_dma_map) to have a single call for app to register and DMA map the= memory. The rte_mem_virt2memseg is not something application needs to unde= rstand, it is used internally by PMDs or other libs.=20 Just FYI. My implementation for mlx4/5 doesn't need to have a separate registration f= or DMA by rte_dma_map() as long as it is included in the memseg list. Registra= tion is done only if Lkey lookup misses and only mem free event is taken to rele= ase it. From my end, the reason why we wanted to have a generic DMA registratio= n was because some people doesn't want to use the new API to make the ext mem inc= luded in the memseg list but want to simply call the API for DMA registration. In a nutshell, mlx4/5 needs users use either rte_extmem_register() or rte_dma_map(). However, it is no problem to call both. Thanks, Yongseok >> [1] >> https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fma >> ils.dpdk.org%2Farchives%2Fdev%2F2018- >> November%2F118175.html&data=3D02%7C01%7Cshahafs%40mellanox.co >> m%7C007a9234feaf42c82f6508d656015eb1%7Ca652971c7d2e4d9ba6a4d1492 >> 56f461b%7C0%7C0%7C636790961244424277&sdata=3DYqwcPEEhJM3I7Toe >> Ne%2BGcbeo%2FmPbYEnNFckoA7ES2Hg%3D&reserved=3D0 >>=20 >> Note: at the time of this writing, there's no release notes >> template, so no release notes updates in this patchset. >> They will be added in later revisions. >>=20 >> Anatoly Burakov (4): >> malloc: separate creating memseg list and malloc heap >> malloc: separate destroying memseg list and heap data >> mem: allow registering external memory areas >> mem: allow usage of non-heap external memory in multiprocess >>=20 >> .../prog_guide/env_abstraction_layer.rst | 63 +++++++-- >> lib/librte_eal/common/eal_common_memory.c | 116 >> +++++++++++++++++ >> lib/librte_eal/common/include/rte_memory.h | 122 >> ++++++++++++++++++ >> lib/librte_eal/common/malloc_heap.c | 104 +++++++++++---- >> lib/librte_eal/common/malloc_heap.h | 15 ++- >> lib/librte_eal/common/rte_malloc.c | 115 +++++++---------- >> lib/librte_eal/rte_eal_version.map | 4 + >> 7 files changed, 434 insertions(+), 105 deletions(-) >>=20 >> -- >> 2.17.1