>What real advantages are there for doing this "in-band" as you say?
Doing this in-band keeps the entire keep-alive protocol within the ULP. It can set the keep-alive message size and retry times. LAP messages are fixed at 256 bytes, add additional traffic on QP 1, and retries are limited by the CM protocol. (Of course, new CM messages would have these same limits, so it's not clear to me that creating new CM messages are a win. New CM messages would allow the CM itself to respond directly to keep-alives though.) A couple disadvantages are that broken connections take longer to detect if the remote node is able to respond to the LAP, and the connection must be able to send and receive. (The latter calls for a general solution being out-of-band.) >Sure, I agree, this would be nice. But I expect this will take a while >to get the standartization rolling. So I think we'll start with the LAP hack >and add support for the new CM message when/if it's there. Okay - is there any real drawback to using LAP other than it 'feels' like a mis-use of the CM protocol? - Sean _______________________________________________ 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
