<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2019 at 9:24 AM Eric Fried <openstack@fried.cc> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> “The rps are in a same subtree” is equivalent to “there exits an rp<br>
> which is an ancestor of all the other rps”<br>
<br>
++<br>
<br>
> I would say yes keep the symmetry because<br>
> <br>
> 1. the expression 1:2:3 is more of symmetry. If we want to make it<br>
> asymmetric, it should express the subtree root more explicitly like<br>
> 1-2:3 or 1-2:3:4.<br>
> 2. callers may not be aware of which resource (VCPU or VF) is provided<br>
> by the upper/lower rp.<br>
>     IOW, the caller - resource retriever (scheduler) -  doesn't want to<br>
> know how the reporter - virt driver - has reported the resouces.<br>
<br>
This.<br>
<br>
(If we were going to do asymmetric, I agree we would need a clearer<br>
syntax. Another option I thought of was same_subtree1=2,3,!4. But still<br>
prefer symmetric.)<br>
<br>
> It enables something like:<br>
> * group_resources=1:2:!3:!4<br>
> which means 1 and 2 should be in the same group but 3 shoudn't be the<br>
> descendents of 1 or 2, so as 4.<br>
<br>
In a symmetric world, this one is a little ambiguous to me. Does it mean<br>
4 shouldn't be in the same subtree as 3 as well?<br>
<br></blockquote><div><br></div><div><div>First, thanks Tetsuro for investigating ways to support such queries. Very much appreciated.</div><div>I
 hope I can dedicate a few time this cycle to see whether I could help 
with implementing NUMA affinity as I see myself as the first consumer of
 such thing :-)</div><div><br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> However, speaking in the design level, the adjacency list model (so<br>
> called naive tree model), which we currently use for nested rps,<br>
> is not good at retrieving subtrees<br>
<snip><br>
<br>
Based on my limited understanding, we may want to consider at least<br>
initially *not* trying to do this in sql. We can gather the candidates<br>
as we currently do and then filter them afterward in python (somewhere<br>
in the _merge_candidates flow).<br>
<br>
> One drawback of this is that we can't use this if you create multiple<br>
> nested layers with more than 1 depth under NUMA rps,<br>
> but is that the case for OvS bandwidth?<br>
<br>
If the restriction is because "the SQL is difficult", I would prefer not<br>
to introduce a "distance" concept. We've come up with use cases where<br>
the nesting isn't simple.<br>
<br>
> Another alternative is having a "closure table" from where we can<br>
> retrieve all the descendent rp ids of an rp without joining tables.<br>
> but... online migration cost?<br>
<br>
Can we consider these optimizations later, if the python-side solution<br>
proves non-performant?<br>
<br></blockquote><div><br></div><br>Huh, IMHO the whole benefits of having SQL with Placement was that we were getting a fast distributed lock proven safe.</div><div class="gmail_quote">Here, this is a read so I don't really bother on any potential contention, but I just wanted to say that if we go this way, we absolutely need to make enough safeguards so that we don't loose the key interest of Placement. This is not trivial either way then.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">-Sylvain</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
efried<br>
.<br>
<br>
<br>
</blockquote></div></div>