Open Stack

> “The rps are in a same subtree” is equivalent to “there exits an rp
> which is an ancestor of all the other rps”

++

> I would say yes keep the symmetry because
> 
> 1. the expression 1:2:3 is more of symmetry. If we want to make it
> asymmetric, it should express the subtree root more explicitly like
> 1-2:3 or 1-2:3:4.
> 2. callers may not be aware of which resource (VCPU or VF) is provided
> by the upper/lower rp.
>     IOW, the caller - resource retriever (scheduler) -  doesn't want to
> know how the reporter - virt driver - has reported the resouces.

This.

(If we were going to do asymmetric, I agree we would need a clearer
syntax. Another option I thought of was same_subtree1=2,3,!4. But still
prefer symmetric.)

> It enables something like:
> * group_resources=1:2:!3:!4
> which means 1 and 2 should be in the same group but 3 shoudn't be the
> descendents of 1 or 2, so as 4.

In a symmetric world, this one is a little ambiguous to me. Does it mean
4 shouldn't be in the same subtree as 3 as well?

> However, speaking in the design level, the adjacency list model (so
> called naive tree model), which we currently use for nested rps,
> is not good at retrieving subtrees
<snip>

Based on my limited understanding, we may want to consider at least
initially *not* trying to do this in sql. We can gather the candidates
as we currently do and then filter them afterward in python (somewhere
in the _merge_candidates flow).

> One drawback of this is that we can't use this if you create multiple
> nested layers with more than 1 depth under NUMA rps,
> but is that the case for OvS bandwidth?

If the restriction is because "the SQL is difficult", I would prefer not
to introduce a "distance" concept. We've come up with use cases where
the nesting isn't simple.

> Another alternative is having a "closure table" from where we can
> retrieve all the descendent rp ids of an rp without joining tables.
> but... online migration cost?

Can we consider these optimizations later, if the python-side solution
proves non-performant?

efried
.