<html>

<body>

<font size=3>At 01:17 PM 10/23/2007, Steve Wise wrote:<br><br>

<br>

<blockquote type=cite class=cite cite="">Sean Hefty wrote:<br>

<blockquote type=cite class=cite cite="">

<blockquote type=cite class=cite cite="">There has been much discussion

on a private thread regarding bug #735 - "dapltest performance tests

don't adhere to iWARP standard" that needs to move to the general

list.</blockquote>This bug would be better titled "iWarp cannot

support uDAPL API". :)<br>

Seriously, the iWarp and uDAPL specs conflict.  One needs to

change.<br><br>

<blockquote type=cite class=cite cite="">Can someone come up with a

solution, possibly in iWARP CM, that will work and insure

interoperability between iWARP devices?</blockquote>I thought the

restriction was there to support switching between streaming and rdma

mode.  If a connection only uses rdma mode, is the restriction

really needed at all?<br>

</blockquote><br>

Yes because all iWARP connections start out as TCP streaming mode

connections, and the MPA startup messages are sent in streaming mode.

Then the connection is  transitioned into FPDU (Framed PDU) mode

using the MPA protocol.</blockquote><br>

Correct.  The IETF was very clear on these requirements (significant

debate occurred over at least 12-18 months) and there is unlikely to be

any traction in changing the iWARP specifications to provide another

mechanism.  Best to provide API that detect which semantics are

required and then if the application cannot adjust, then it cannot use

the iWARP semantics.<br><br>

BTW, if one uses the SDP port mapper protocol (see the IETF SDP

specification), one can detect from the start that RDMA is being used and

one could start in RDMA mode sans the MPA requirement.   The

SDP port mapper protocol also enables one to apply various other policies

such as determining whether the application / remote node session should

be allowed to run over RDMA or not - simple point of control for

management. <br><br>

Mike</font></body>

</html>