On 7/17/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > But to be fair, it will be difficult to enable both QoS and local PR > > caching. To me, this would be the strongest reason against using it. > > However, QoS places additional burden on the SA, which will make scaling > > even more challenging. > > 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? > > 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"? Or, thanks for rescuing this post. I think this is an important question. If we merge the local SA stuff, then are we creating a problem for dealing with QoS? Are we going to have to revert the local SA stuff once the QoS stuff is available? Or is there at least a sketch of a plan on how to handle this?
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. -- Hal - R.
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
