> > 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
