<br><br><div><span class="gmail_quote">On 12/5/05, <b class="gmail_sendername">Sean Hefty</b> <<a href="mailto:sean.hefty@intel.com">sean.hefty@intel.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm like to start a discussion of having the CMA support SDP.  To do this, I'd<br>like to propose adding the following optional call to the CMA:<br><br>enum rdma_cm_protocol {<br>        RDMA_CM_DEFAULT,<br>        RDMA_CM_SDP
<br>};<br><br>/**<br> * rdma_set_protocol - Associate a specific connection protocol with the<br> *   RDMA identifier.<br> *<br> * @id: RDMA identifier.<br> * @protocol: Connection protocol.<br> * @version: Connection protocol version, or 0 to use the default.
<br> *<br> * This is an optional call that may be made to specify that the indicated<br> * connection protocol be used when establishing connections to the<br> * associated RDMA identifier.<br> */<br>int rdma_set_protocol(struct rdma_cm_id *id, enum rdma_cm_protocol protocol,
<br>                      int
version);<br><br><br>For most users, this routing would not need to be called.  If called by SDP,<br>then the CMA would use SDP's service IDs and private data format.  The CMA would<br>be responsible for setting the local port number and source/destination IP
<br>addresses.  All other fields would be set by the caller.<br><br>Comments?<br><br>- Sean<br><br></blockquote></div><br>
Who is the intended consumer of this API?<br>
<br>
My understanding is that there are few to zero end applications that use SDP<br>
knowingly. They use the sockets API, which is intercepted at one layer or another<br>
by a middleware library, and it is that middleware library that uses SDP.<br>
<br>
If SDP middleware libraries are the only users of SDP-style connection setup<br>
then it would make more sense to have a distinct method to serve that purpose<br>
rather than having an enum/option flag on the main method.<br>
<br>
In particular I would not want end applications to expected to "request SDP"<br>
merely to get an offloaded SOCK_STREAM connection. On an IB network<br>
the advantage of SDP over TCP/IP over IPoIB is a no-brainer. But the<br>
tradeoff between the host TCP/IP stack, an offload TCP/IP stack and<br>
SDP/iWARP is a much more complex tradeoff.<br>
<br>
Depending on who the envisioned user is we may need to distinquish<br>
between 'definitely use SDP, because I know my peer is using SDP'<br>
and 'offloaded by whatever mutually available methods'.<br>
<br>
Those questions are irrelevant if the call is made from the intercept<br>
library itself, as that they were decided by controlling the intercept.<br>
But if the intercept library is the primary user of this option then<br>
I defnitely think that a separate method is better than an option param.<br>
<br>