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

[Jason Gunthorpe]

On Wed, Jul 18, 2007 at 12:40:07AM -0400, Hal Rosenstock wrote:

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

IMHO, I still think that without some kind of SM/SA sourced
invalidation mechanism all client side caching (including the ipoib
stuff we have now) is a bad idea. There just isn't any way to maintain
coherence. I think QoS is just a specific case of why.. Routers are
also likely to cause similar kinds of headaches. There are even a
bunch of other corner cases even with out those two.

It seems to me this would be alot better as a patch set to let a user
space daemon have first dibs at responding to a PR lookup. Then the
labs could have a special daemon that worked with the SA in a
vendor-specific way to do replication and get some big speed
ups. This should be pretty easy if you use a shared filesystem to
distribute a routing database produced by opensm.

But I'm not working on this stuff ;)

Jason