On 7/13/07, <b class="gmail_sendername">Sean Hefty</b> <<a href="mailto:mshefty@ichips.intel.com">mshefty@ichips.intel.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
>  - Take a look at Sean's local SA caching patches.  I merged<br>>    everything else from Sean's tree, but I'm still undecided about<br>>    these.  I haven't read them carefully yet, but even aside from that
<br>>    I don't have a good feeling about whether there's consensus about<br>>    this yet.  Any opinions about merging, for or against, would be<br>>    appreciated here.<br><br>But to be fair, it will be difficult to enable both QoS and local PR
<br>caching.  To me, this would be the strongest reason against using it.<br>However, QoS places additional burden on the SA, which will make scaling<br>even more challenging.</blockquote><div><br>
my understanding is that the local sa does a path-query where all the
fields except for the SGID are wildcard-ed. This means we expect the
result to be a table of all the paths from this port to every other
port on the fabrics for every pkey which this port is a member of etc,
correct? <br>
<br>
How do you plug here  the QoS concept of SID in the path query?
are you expecting the SA to realize what are all the services for which
this port is a "member"? does the proposed definision for QoS
management at the SA defines "services per gids" isn't it "what SL to
user per Service"?<br>
<br>
</div></div>Or.<br>