From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrien Mazarguil Subject: Re: [PATCH v1 09/29] mem: add iovec-like allocation wrappers Date: Thu, 12 Oct 2017 13:07:53 +0200 Message-ID: <20171012110753.GR13551@6wind.com> References: <18771436831105304b9f7c133cc51e8c867f4273.1507730496.git.adrien.mazarguil@6wind.com> <51cd7192-003e-ee97-e511-4539eff580f0@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev@dpdk.org, Thomas Monjalon To: Ferruh Yigit Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 282F21B21E for ; Thu, 12 Oct 2017 13:08:04 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id m72so23515319wmc.0 for ; Thu, 12 Oct 2017 04:08:04 -0700 (PDT) Content-Disposition: inline In-Reply-To: <51cd7192-003e-ee97-e511-4539eff580f0@intel.com> 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 Wed, Oct 11, 2017 at 10:58:45PM +0100, Ferruh Yigit wrote: > On 10/11/2017 3:35 PM, Adrien Mazarguil wrote: > > These wrappers implement the ability to allocate room for several disparate > > objects as a single contiguous allocation while complying with their > > respective alignment constraints. > > > > This is usually more efficient than allocating and freeing them > > individually if they are not expected to be reallocated with rte_realloc(). > > > > A typical use case is when several objects that cannot be dissociated must > > be allocated together, as shown in the following example: > > > > struct b { > > ... > > struct d *d; > > } > > > > struct a { > > ... > > struct b *b; > > struct c *c; > > } > > > > struct rte_malloc_vec vec[] = { > > { .size = sizeof(struct a), .addr = &ptr_a, }, > > { .size = sizeof(struct b), .addr = &ptr_b, }, > > { .size = sizeof(struct c), .addr = &ptr_c, }, > > { .size = sizeof(struct d), .addr = &ptr_d, }, > > }; > > > > if (!rte_mallocv(NULL, vec, RTE_DIM(vec))) > > goto error; > > > > struct a *a = ptr_a; > > > > a->b = ptr_b; > > a->c = ptr_c; > > a->b->d = ptr_d; > > ... > > rte_free(a); > > > > Signed-off-by: Adrien Mazarguil > > Acked-by: Nelio Laranjeiro > > Hi Adrien, > > Why there is an eal patch in the middle of the mlx4 patchset? Well, it was probably a mistake to leave it as is; it was more or less there from the beginning and some other stuff I intended to send also relied on it, which is why it got promoted to EAL. This series was actually supposed to be sent much sooner but... Anyway, I thought it could be useful to share it through EAL, and I secretly hoped no one would notice. > I believe this shouldn't go in via next-net tree, and should be reviewed > properly. > > I am behaving more flexible for PMD patches about the process and > timing, because their scope is limited. > PMD patches can break at most the PMD itself and if the maintainer is > sending the patch, they should be knowing what they are doing, so vendor > gets the responsibility for their own driver. I am paying majority of > care to be sure it doesn't break others. > > But ethdev and eal way beyond those flexibility, because their scope is > much larger. > > Can you please extract this patch from the patchset? I'll submit v2 shortly to address this issue. I remain open to comments on the usefulness of these functions, which I'll eventually re-send as a separate patch. -- Adrien Mazarguil 6WIND