<br><br>
<div><span class="gmail_quote">On 7/17/07, <b class="gmail_sendername">Roland Dreier</b> <<a href="mailto:rdreier@cisco.com">rdreier@cisco.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">> > 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.<br>><br>> my understanding is that the local sa does a path-query where all the fields<br>> except for the SGID are wildcard-ed. This means we expect the result to be a
<br>> table of all the paths from this port to every other port on the fabrics for<br>> 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
<br>> expecting the SA to realize what are all the services for which this port is<br>> a "member"? does the proposed definision for QoS management at the SA<br>> defines "services per gids" isn't it "what SL to user per Service"?
<br><br>Or, thanks for rescuing this post.<br><br>I think this is an important question.  If we merge the local SA<br>stuff, then are we creating a problem for dealing with QoS?  Are we<br>going to have to revert the local SA stuff once the QoS stuff is
<br>available?  Or is there at least a sketch of a plan on how to handle<br>this?</blockquote>
<div>
<div> </div>
<div>Is the worst case that local SA cache and QoS on an end node are mutually exclusive ? I think there is a way to shut off the local SA cache.</div>
<div> </div>
<div>-- Hal</div></div><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">- R.<br>_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openfabrics.org">
general@lists.openfabrics.org</a><br><a href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general</a><br><br>To unsubscribe, please visit <a href="http://openib.org/mailman/listinfo/openib-general">
http://openib.org/mailman/listinfo/openib-general</a><br></blockquote></div><br>