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.
BTW, I think we might want to avoid retries altogether: if LAP
timed out, we can just re-create the connection.
The CM currently retries LAP messages based on the value of the REQ max
CM retries, but I don't see why this couldn't change.
(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.)
OTOH, using QP1 makes it easier to separate rare keepalives
from fast-path data packet receive path.
I was thinking more along the lines of whether to use the CM LAP message
or create a new CM message for handling keep-alive. The best argument I
can come up with for creating a new message is that it 'seems'
cleaner... Anyway, I agree that using LAP would be the best approach
for now.
- 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
