Hal Rosenstock wrote:
As the end node cannot know the policies the SM used for routing, etc.,
path records are insufficient in terms of some of the interesting
characteristics for filtering like path independence (as fault
independent as possible).
This patch doesn't handle policy. It only stores multiple path records.
Also, it seems like the argument can go both ways here. The SM doesn't know the
policies of the applications or their traffic patterns. A distributed
application may want paths from nodes A to B to have path independence from
paths from nodes C to D. Can the SM handle such requests?
There's also a 1.2 erratum which enhances SA MultiPathRecord to support
scoping of S/DGIDs. It supports explicit, same node, same system with
and without high availability (separate HCAs). That could also be used
when supported by the SA.
It shouldn't be hard to change the path query from GetTable to GetMulti, once
the MAD layer supports dual-RMPP.
The API looks fine to me. One thing to note is to keep an eye on the
lookups done on the local database and possibly optimizing them if
needed.
Tracking path usage becomes difficult, and would likely require involving the
CM, and possibly address handle creation (for UD QPs that didn't use SIDR).
When the cache is updated, checks would need to be added to see if a path is
currently in the cache, and invalid paths would need to be removed. There would
be a lot of additional work needed to do this.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
