From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6IoUGYxKESiKY1ps+b9LrB6XULXs8dm94Fc/l2rfbC8=; b=guJVCGdwIxU/UBzUkWlnuDT3YLMQqB0LuDHFbVOFctLywdmDJ0xEEw+IIi+9HR5+Kn cJ0x9E31VGfLXSU1oGuYqOucbdHjN3rjZ1kGqZLQiJbP9r+vfU3bbTH4xW6CKBtpWNc0 g6UjAK3q/r8D+K3yS6sKYDLLfsLUnaZ6xhwmq7puRsfhvA+SzbXpzvs5Rl0zbUvQ3KOa S7Rht67z8haw5tBod55T51w1wNEIXhl3CdjhVhL5zvtVP9qz2UNMBJShxdT4x78dnBNc sUQc6zCmSMhWoc3Lm2eLINOkoP45NY5XyHKGzEYY6mAqUNkK6G0mrI7iR1Ki4kwAeLXK oNiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6IoUGYxKESiKY1ps+b9LrB6XULXs8dm94Fc/l2rfbC8=; b=eHdVn7f45/zTfhRJxNHyEhBuyC8XR5MnFDFVDxk90vaADGAJB2RM0kq14zI6ws1B1D bmAzPOznvpT3OlNURZljK6W/GITVhMlk55V+QicYyaoUiooe7/i/Y5IU0e2TC9WKsuZr lgr9pADAMplbawSGjKhbSvwsKQMk6F/+ZGmlJKACYEBJCiyL77rYfgKSjPW15IA1KShK FrmO30cYbY2tMzT3ST2EtmldhxxFzO1C8X+dfZek9+6hEuAm6GWJnw0dnWRRcXnZd90f Eff1cKV8CLt4xl3hjUNriR5ZstpjegBKwZFFaBMgDxDlLe5raEq0uOnxN4KammP1I29t KOpg== X-Gm-Message-State: AMCzsaUjoaRoQrMPsh7I9gM8GZMVifqeTUn6mlKVLbXUxkWAU5Ok5wnn kLToWbmGcJUS7iqQdSSC+gpAzw== X-Google-Smtp-Source: AOwi7QDZA6dRKD8s/IN3ksIeU74ab0GmenJ0fsIx+j9X4OdUD9lp8TO6E7ykhkv0bwhqELKXpUJ2/A== X-Received: by 10.223.156.144 with SMTP id d16mr1913169wre.29.1507806484483; Thu, 12 Oct 2017 04:08:04 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id k105sm23757118wrc.90.2017.10.12.04.08.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Oct 2017 04:08:03 -0700 (PDT) Date: Thu, 12 Oct 2017 13:07:53 +0200 From: Adrien Mazarguil To: Ferruh Yigit Cc: dev@dpdk.org, Thomas Monjalon 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 Content-Disposition: inline In-Reply-To: <51cd7192-003e-ee97-e511-4539eff580f0@intel.com> Subject: Re: [dpdk-dev] [PATCH v1 09/29] mem: add iovec-like allocation wrappers 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: Thu, 12 Oct 2017 11:08:05 -0000 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