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

[Hal Rosenstock]

On 7/17/07, Roland Dreier <rdreier at cisco.com> 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
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit
> http://openib.org/mailman/listinfo/openib-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20070718/c6b3f092/attachment.html>