Re: [PATCH v1 09/29] mem: add iovec-like allocation wrappers

[Adrien Mazarguil <adrien.mazarguil@6wind.com>]

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 <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?

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