Re: [ofa-general] Further 2.6.23 merge plans...

[Roland Dreier]

 > > 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?

 - R.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/