Re: [RFC PATCH v5 23/26] util: Add iova_tree_alloc

[Eugenio Perez Martin <eperezma@redhat.com>]

On Thu, Jan 27, 2022 at 12:25 PM Peter Xu <peterx@redhat.com> wrote:
>
> On Thu, Jan 27, 2022 at 11:09:44AM +0100, Eugenio Perez Martin wrote:
> > > > +/**
> > > > + * Try to accomodate a map of size ret->size in a hole between
> > > > + * max(end(hole_left), iova_start).
> > >
> > > I think this functions need the most comments, and above sentence is more or
> > > less not sounding correct... My try...
> > >
> > > /*
> > >  * Try to find an unallocated IOVA range between LEFT and RIGHT elements.
> > >  *
> > >  * There're three cases:
> > >  *
> > >  * (1) When LEFT==NULL, RIGHT must be non-NULL and it means we're iterating at
> > >  *     the 1st element.
> > >  *
> > >  * (2) When RIGHT==NULL, LEFT must be non-NULL and it means we're iterating at
> > >  *     the last element.
> > >  *
> > >  * (3) When both LEFT and RIGHT are non-NULL, this is the most common case,
> > >  *     we'll try to find a hole between LEFT and RIGHT mapping.
> > >  */
> > >
> >
> > This is also called with left == NULL and right == NULL in the first
> > allocation with an empty tree. This allows iova_tree_alloc to have the
> > same code path both if the three is empty or not.
> >
> > But I can add the use cases in the doc for sure.
>
> Ah, right.
>
> >
> > > > + *
> > > > + * @args Arguments to allocation
> > > > + */
> > > > +static bool iova_tree_alloc_map_in_hole(const struct IOVATreeAllocArgs *args)
> > > > +{
> > > > +    const DMAMap *left = args->hole_left, *right = args->hole_right;
> > > > +    uint64_t hole_start, hole_last;
> > > > +
> > > > +    if (right && right->iova + right->size < args->iova_begin) {
> > > > +        return false;
> > > > +    }
> > > > +
> > > > +    if (left && left->iova > args->iova_last) {
> > > > +        return false;
> > > > +    }
> > > > +
> > > > +    hole_start = MAX(left ? left->iova + left->size + 1 : 0, args->iova_begin);
> > > > +    hole_last = MIN(right ? right->iova : HWADDR_MAX, args->iova_last);
> > >
> > > I assume these values should be always inclusive, hence
> > >
> > > s/right->iova/right->iova + 1/
> > >
> > > ?
> > >
> >
> > Right, it is confusing the way it's written. But I think it should be
> > right->iova - 1 in any case to make it the hole last element, isn't
> > it?
>
> I was thinking "-1" but I failed to make it coherent with the thought when
> typing.. Heh.
>
> >
> > Would it work better to rename variable hole_last to hole_end? If not,
> > we have a special case of the second allocation when iova_begin == 0:
> > - We successfully allocate a DMAMap of size N. By the way the
> > algorithm works,  it starts at 0, so [0, N] is allocated.
>
> If we're always talking about inclusive ranges, shouldn't it be [0, N-1]?
>

I meant DMAMap size, which is already inclusive.

> > - We try to allocate a second one of size M. At the first iteration,
> > "right" is the previously allocated DMAMap.
> > Using the -1 trick we get hole_end == HWADDR_MAX.
>
> I'm not sure I get the point, but both naming look fine to me.  As long as we
> use inclusive ranges, then hole_end/last will be limited to HWADDR_MAX.
>

Sorry, I think you were right from the beginning, because with _end we
cannot handle the case of right == NULL well. I'll rewrite with the
-1, taking into account the underflow.

Please let me know if you have more concerns or you come up with more
ideas to improve the patch.

Thanks!

> > > > +static gboolean iova_tree_alloc_traverse(gpointer key, gpointer value,
> > > > +                                         gpointer pargs)
> > > > +{
> > > > +    struct IOVATreeAllocArgs *args = pargs;
> > > > +    DMAMap *node = value;
> > > > +
> > > > +    assert(key == value);
> > > > +
> > > > +    iova_tree_alloc_args_iterate(args, node);
> > > > +    if (args->hole_left && args->hole_left->iova > args->iova_last) {
> > >
> > > IMHO this check is redundant and can be dropped, as it's already done in
> > > iova_tree_alloc_map_in_hole().
> > >
> >
> > Assuming we add "iova_found" to iova_tree_alloc_map_in_hole to
> > IOVATreeAllocArgs as you propose, it returns true if we are able to
> > allocate a DMAMap entry, so no more iterations are needed. But if it
> > returns false, it simply means that DMAMap cannot be allocated between
> > left (or iova_begin) and right (iova_end). It doesn't tell if you can
> > keep iterating or not. In other words, false == keep iterating if you
> > can.
> >
> > This other check signals the end of the available hole, and to avoid
> > iterating beyond iova_last in the (unlikely?) case we have more nodes
> > to iterate beyond that.
> >
> > I'll try to make it more explicit.
>
> Makes sense.  Comment works.
>
> Thanks,
>
> --
> Peter Xu
>