From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 605D21B38D for ; Wed, 14 Feb 2018 09:04:52 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D303D20D0E; Wed, 14 Feb 2018 03:04:51 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 14 Feb 2018 03:04:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=KSDbunRF39LInmwesokeIFdlr9 Y/6LC7soujAcz1Li8=; b=dybFmsojsgpPXO9EGFNHCvW9nvrg07m5Y4Lj+bB6jB WUksnx3EKdagpss9QmC78NHOs3wNkgJtHvab+IBIKfML9SJyvO4BcMgXGqPoYMfQ /awPb5rc6c1XKeNLwL6Kdg/yC8MwmcoQqSqh8/OMVUBW/q/4mrKCHPBXy9++XhBZ w= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KSDbun RF39LInmwesokeIFdlr9Y/6LC7soujAcz1Li8=; b=FnJnTy2oHbZOvcVQ0zxTfr Mf3HfhHm/9XxQyMsrSNZ3ZBI2ohr4SLXmxKhEjuiGq8kXf5XKhEPj0c2ShPa0f/E EAzEHGp1pWjpuAJt8kXb3xexOCY9HyNgPorgsSX74jBrJ6GzGFmgGNRvYAWaq1+C XU/KcwrTN25hIqHABEwoWrO8tlQ06b/ywHLEY2cpAbPuhCXmO4pKcgHSeiO/qNWy BwUYpHnZ1YaNUbWHMWkNAj7nrqNfwgxdKB+F2P+LA7TLIyoMEDz2KyChBTGnF956 BD2ZoXVwobijl4gl/2taMQSk6a7OgArPq7HoS1iI5uNwCkeox1I5HArbwfujDgjg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 72D7A2469C; Wed, 14 Feb 2018 03:04:51 -0500 (EST) From: Thomas Monjalon To: Anatoly Burakov 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 , 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 Date: Wed, 14 Feb 2018 09:04:39 +0100 Message-ID: <1667872.djnhp43hg1@xps> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 08:04:52 -0000 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? Could it be a bit-field allowing to combine some properties? Does it make sense to have "DMA" as one of the purpose? 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. +Cc more people (6WIND, Cavium, Chelsio, Mellanox, Netronome, NXP, Solarflare) in order to trigger a discussion about the ideal requirements.