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