From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 38FACA317C for ; Thu, 17 Oct 2019 18:41:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B652D1E929; Thu, 17 Oct 2019 18:41:10 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 068CC1E915 for ; Thu, 17 Oct 2019 18:41:08 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id o18so2673829ilo.9 for ; Thu, 17 Oct 2019 09:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWKL0+L7Nd/uN7+TiBjPK05YQf6OOIMKACrXUW+pi7U=; b=cxxsOamWNLpR8iFTAe5AHlv2hUGxWCq2WHPrpS6fL/oMEpDrSKghbsNQzzxypla45/ dl1V/9OZjE4ONVD+4T4AdUPfI+3zP8qeOnGftCulYGuEX8fZ4Wj9+ciXlEIbLu+1j4BN J9sUjW+Ni1YeEmXgR7Iaf90qgDwQClysWDfXiUsmlDWTpiywUFdA3wAQnM2nReZF0O4e ds3M4tHSqKEwdHJowpj5AiMMXZfxBbnGSVoR94xAh2SJGDv9eNpx8NFQ1r9E/eC4zO/s YF+eSDQk2XSQfN0ci87BJM6TA3mjc4wrx3nV56WYpQ/VNU/rWi970N/LR337pL6V6wnc eTYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JWKL0+L7Nd/uN7+TiBjPK05YQf6OOIMKACrXUW+pi7U=; b=DXF1+y8Itf1k9hwCBD4a+I8Xw7WDQXrbgU+U9ZMeFCsaa7njRIHST37nNMRQ29rxXq ChNpG5Ezs5UoxYRQ0K29F+kptms0tklgOl4MEIEDcKbPcmZCgYAvtmwX61+CchN6I7iD EsCv34jwLzxtw0P/7RhvrpfLUepU9XnIE1lBiD80noZixSewX1x4nF0xC0rYvlTxn8yE 5Pjxtnrc+s3Svr0mSUp5Ga+vyYAuCGpxSZ92CdcBq0xLxC9ob+VBKwbdrhNACuBWs3tn pIurNnPF5+YuH/K9nOsFWnlYBsF1PzVzsyDZC+mKNmtpJg6cbe2jPGhx1pcU4H8TWgMN qBuQ== X-Gm-Message-State: APjAAAUfB7B/+/+ZH1h0QaT69cGfCM7/u9RKo7K2GETRnsdIzuo4QM7b dkzhCZE6AVgRbAJL0mYVlO5nBK68kVv8W2/C1N4= X-Google-Smtp-Source: APXvYqwQHUc18OdcpPRAZuF3jJUxxxg5ByTQ7peayUj8B96sHbnEikJIDRh+NKiQf9ZOn99W6P/fS9gBL5rtwDmecFk= X-Received: by 2002:a92:c60f:: with SMTP id p15mr4860171ilm.162.1571330468122; Thu, 17 Oct 2019 09:41:08 -0700 (PDT) MIME-Version: 1.0 References: <1571295301-25911-1-git-send-email-xuemingl@mellanox.com> In-Reply-To: From: Jerin Jacob Date: Thu, 17 Oct 2019 22:10:57 +0530 Message-ID: To: "Xueming(Steven) Li" Cc: Olivier Matz , Andrew Rybchenko , dpdk-dev , Asaf Penso , Ori Kam , Stephen Hemminger Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC] mempool: introduce indexed memory pool 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Oct 17, 2019 at 6:43 PM Xueming(Steven) Li wrote: > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Thursday, October 17, 2019 3:14 PM > > To: Xueming(Steven) Li > > Cc: Olivier Matz ; Andrew Rybchenko > > ; dpdk-dev ; Asaf Penso > > ; Ori Kam > > Subject: Re: [dpdk-dev] [RFC] mempool: introduce indexed memory pool > > > > On Thu, Oct 17, 2019 at 12:25 PM Xueming Li wrote: > > > > > > Indexed memory pool manages memory entries by index, allocation from > > > pool returns both memory pointer and index(ID). users save ID as u32 > > > or less(u16) instead of traditional 8 bytes pointer. Memory could be > > > retrieved from pool or returned to pool later by index. > > > > > > Pool allocates backend memory in chunk on demand, pool size grows > > > dynamically. Bitmap is used to track entry usage in chunk, thus > > > management overhead is one bit per entry. > > > > > > Standard rte_malloc demands malloc overhead(64B) and minimal data > > > size(64B). This pool aims to such cost saving also pointer size. > > > For scenario like creating millions of rte_flows each consists of > > > small pieces of memories, the difference is huge. > > > > > > Like standard memory pool, this lightweight pool only support fixed > > > size memory allocation. Pools should be created for each different > > > size. > > > > > > To facilitate memory allocated by index, a set of ILIST_XXX macro > > > defined to operate entries as regular LIST. > > > > > > By setting entry size to zero, pool can be used as ID generator. > > > > > > Signed-off-by: Xueming Li > > > --- > > > lib/librte_mempool/Makefile | 3 +- > > > lib/librte_mempool/rte_indexed_pool.c | 289 +++++++++++++++++++++ > > > lib/librte_mempool/rte_indexed_pool.h | 224 ++++++++++++++++ > > > > Can this be abstracted over the driver interface instead of creating a new APIS? > > ie using drivers/mempool/ > > The driver interface manage memory entries with pointers, while this api uses u32 index as key... I see. As a use case, it makes sense to me. Have you checked the possibility reusing/extending lib/librte_eal/common/include/rte_bitmap.h for bitmap management, instead of rolling a new one?