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.mazarg...@6wind.com>
> > Acked-by: Nelio Laranjeiro <nelio.laranje...@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
