[ofa-general] Re: [RFC] [PATCH 0/3] 2.6.22 or 23 ib: add pathrecord cache

[Michael S. Tsirkin]

> Quoting Sean Hefty <sean.hefty at intel.com>:
> Subject: RE: [ofa-general] Re: [RFC] [PATCH 0/3] 2.6.22 or 23 ib: add pathrecord cache
> 
> >We could solve this by implementing a process running on the same node as the
> >SA.
> >And it's probably not too hard to add a way for opensm to spit out
> >the table into an external file when it gets a signal or something.
> 
> I agree that there are ways to solve this, but those solutions won't work with
> existing SAs and define a new SA interface.  If we're willing to break
> compatibility or add extensions, we could also extend the SA to provide better
> support for caching.  For example, add a new 'path updated' trap.

One difficulty here 

> IMO, I don't think that there's a huge issue initially populating the cache.
> The problems all seem to fall into keeping it updated.  I originally thought
> this would have been a bigger deal, but given that ipoib doesn't update its
> cache, it doesn't seem to be an issue in practice.

Maybe, but there might be several other reasons for this.

One might be that IPoIB is slower than link speeds,
so e.g. miscalculating the rate still does not cause network failures.
Another might be that people run TCP mostly, which
is very good at recovering from failures, so if you get the LID
right, the rest of the values being off might not matter.

In short, I'm not sure the fact that IPoIB works
means we can copy it's caching over safely.

-- 
MST