From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ferruh.yigit@intel.com>
Received: from mga06.intel.com (mga06.intel.com [134.134.136.31])
 by dpdk.org (Postfix) with ESMTP id 361721B206
 for <dev@dpdk.org>; Wed, 11 Oct 2017 23:58:47 +0200 (CEST)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by orsmga104.jf.intel.com with ESMTP; 11 Oct 2017 14:58:46 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.43,362,1503385200"; d="scan'208";a="909054374"
Received: from unknown (HELO [10.241.225.21]) ([10.241.225.21])
 by FMSMGA003.fm.intel.com with ESMTP; 11 Oct 2017 14:58:45 -0700
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: dev@dpdk.org
References: <cover.1507730496.git.adrien.mazarguil@6wind.com>
 <18771436831105304b9f7c133cc51e8c867f4273.1507730496.git.adrien.mazarguil@6wind.com>
From: Ferruh Yigit <ferruh.yigit@intel.com>
Message-ID: <51cd7192-003e-ee97-e511-4539eff580f0@intel.com>
Date: Wed, 11 Oct 2017 22:58:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <18771436831105304b9f7c133cc51e8c867f4273.1507730496.git.adrien.mazarguil@6wind.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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 <dev.dpdk.org>
List-Unsubscribe: <http://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: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 21:58:47 -0000

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 <adrien.mazarguil@6wind.com>
> Acked-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>

Hi Adrien,

Why there is an eal patch in the middle of the mlx4 patchset?

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?

Thanks,
ferruh