From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <anatoly.burakov@intel.com> Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id ABDF01B1B6 for <dev@dpdk.org>; Wed, 14 Feb 2018 11:07:50 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 02:07:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,511,1511856000"; d="scan'208";a="174965234" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.71]) ([10.237.220.71]) by orsmga004.jf.intel.com with ESMTP; 14 Feb 2018 02:07:44 -0800 To: Thomas Monjalon <thomas@monjalon.net> Cc: dev@dpdk.org, andras.kovacs@ericsson.com, laszlo.vadkeri@ericsson.com, keith.wiles@intel.com, benjamin.walker@intel.com, bruce.richardson@intel.com, Yongseok Koh <yskoh@mellanox.com>, nelio.laranjeiro@6wind.com, olivier.matz@6wind.com, rahul.lakkireddy@chelsio.com, jerin.jacob@cavium.com, hemant.agrawal@nxp.com, alejandro.lucero@netronome.com, arybchenko@solarflare.com, ferruh.yigit@intel.com References: <cover.1513681966.git.anatoly.burakov@intel.com> <1667872.djnhp43hg1@xps> From: "Burakov, Anatoly" <anatoly.burakov@intel.com> Message-ID: <38b1d748-f815-5cf6-acea-e58d291be40d@intel.com> Date: Wed, 14 Feb 2018 10:07:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1667872.djnhp43hg1@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK 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> X-List-Received-Date: Wed, 14 Feb 2018 10:07:52 -0000 On 14-Feb-18 8:04 AM, Thomas Monjalon wrote: > Hi Anatoly, > > 19/12/2017 12:14, Anatoly Burakov: >> * Memory tagging. This is related to previous item. Right now, we can only ask >> malloc to allocate memory by page size, but one could potentially have >> different memory regions backed by pages of similar sizes (for example, >> locked 1G pages, to completely avoid TLB misses, alongside regular 1G pages), >> and it would be good to have that kind of mechanism to distinguish between >> different memory types available to a DPDK application. One could, for example, >> tag memory by "purpose" (i.e. "fast", "slow"), or in other ways. > > How do you imagine memory tagging? > Should it be a parameter when requesting some memory from rte_malloc > or rte_mempool? We can't make it a parameter for mempool without making it a parameter for rte_malloc, as every memory allocation in DPDK works through rte_malloc. So at the very least, rte_malloc will have it. And as long as rte_malloc has it, there's no reason why memzones and mempools couldn't - not much code to add. > Could it be a bit-field allowing to combine some properties? > Does it make sense to have "DMA" as one of the purpose? Something like a bitfield would be my preference, yes. That way we could classify memory in certain ways and allocate based on that. Which "certain ways" these are, i'm not sure. For example, in addition to tagging memory as "DMA-capable" (which i think is a given), one might tag certain memory as "non-default", as in, never allocate from this chunk of memory unless explicitly asked to do so - this could be useful for types of memory that are a precious resource. Then again, it is likely that we won't have many types of memory in DPDK, and any other type would be implementation-specific, so maybe just stringly-typing it is OK (maybe we can finally make use of "type" parameter in rte_malloc!). > > How to transparently allocate the best memory for the NIC? > You take care of the NUMA socket property, but there can be more > requirements, like getting memory from the NIC itself. I would think that we can't make it generic enough to cover all cases, so it's best to expose some API's and let PMD's handle this themselves. > > +Cc more people (6WIND, Cavium, Chelsio, Mellanox, Netronome, NXP, Solarflare) > in order to trigger a discussion about the ideal requirements. > -- Thanks, Anatoly