>> Note that with >> a MAD interface, kernel modules would still have access to >> any cached data. I >> also wanted to stick with usermode to allow saving the cache >> to disk, so that it >> would be available immediately after a reboot. (My >> assumption being that >> changes to the network topology would be rare, so we could >> optimize around a >> stable network design.) >It is risky to assume that PathRecords would stay the same across a node >reboot. It is very likely that the SM could assign different LIDs or if the >node is down for an extended period other things in the fabric could have >significantly changed.
OpenSM currently maintains LIDs between system reboots, and I believe that this is desirable for fast fabric bring-up. And I believe that this is a desirable feature for any SM to have. In any case, a local LID change is trivial to detect and can easily be used to invalidate the entire cache. Likewise, the cache could automatically be flushed if not updated for some specified time period, or if some other defined event occurred - such as a GUID change on the local HCA. Overall, I think that the risk here is low. >> As a related topic, there will be a separate SA client >> interface defined that >> will generate SA query MADs for the user. >Given the complexity of the RMPP protocol and the subtle bugs which everyone >has encountered while implementing and debugging it (timeouts, retries, abort, >window size management, class header offset, etc), it would be best to limit >the number of copies of this protocol within the system. Keeping the RMPP >details hidden just in the kernel would be best. An analogy might be the way >sockets hides the details of the TCP/IP protocol from applications. While I'm >not aware of any changes in the works, we all remember the significant changes >which occurred between IBTA 1.0 and IBTA 1.1 in the RMPP area. If any similar >significant revision to the protocol occurred it would be best to have it all >implemented in just one place. RMPP is implemented by the MAD layer, and is hidden to any clients using the MAD services. There will still only be a single RMPP implementation in the stack. - 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
