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

[Sean Hefty]

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

These are not full proof mechanisms, but the SA does have client re-registration
and GID in/out of service events that the local SA responds to.  Anything beyond
that becomes vendor specific.  The local SA exposes the ability for a user space
application to force an update of the cache, and leaves the refresh policy up to
the user.  In our use model, we force a refresh immediately before starting a
large MPI job.

Nothing precludes a user space daemon from updating the cache at timed
intervals, or from communicating with an SA in some vendor defined way to
maintain coherency.  I'm only trying to provide the kernel framework.  (We can
debate whether another framework would have been better, and I've held this
discussion on the list before...)  I do envision someone creating user space
applications to control refreshes and, with local SA extensions, allow
pre-loading of the cache, updates to specific paths, etc.

We can gain additional benefits by integrating the local SA tighter with the
stack.  For example, the CM could update the local SA on path migration events
or CM message timeouts.

For now, I want to start with a fairly simple framework that's useful and
extensible.  And, IMO, I don't believe that the cache coherency issues are
reason enough alone to prevent merging this patch.

- Sean