
<html>

<body>

<font size=3>At 09:16 PM 2/6/2006, Sean Hefty wrote:<br>

<blockquote type=cite class=cite cite="">>The requirement is to

provide an API that supports RDMA writes with immediate<br>

>data.  A send that follows an RDMA write is not immediate data,

and the API<br>

>should not be constructed around trying to make it so.<br><br>

To be clear, I believe that write with immediate should be part of the

normal<br>

APIs, rather than an extension, but should be designed around those

devices that<br>

provide it natively.<br>

</blockquote><br>

One thing to keep in mind is that the IBTA workgroup responsible for the

transport wanted to eliminate immediate data support entirely but it was

retained solely to enable VIA application migration (even though the

application base was quite small).  If that requirement could have

been eliminated, then it would have been gone in a heart beat. 

Given a RDMA-WRITE followed by a SEND provides the same application

semantics based on the use models, iWARP chose not to support immediate

data.  <br><br>

So, here we have a long discussion on attempting to perpetuate a concept

that is not universal across transports and was deemed to have minimal

value that most wanted to see removed from the architecture.  One

has to question the value of trying to develop any API / software to

support immediate data instead of just enabling the preferred method

which is RDMA WRITE - SEND.  I agree with those who have contended

that this is difficult to do in a general purpose fashion.  When all

of this is taken into account, it seems the only good engineering answer

is to eliminate immediate data support by the software and focused on the

method that works across all interconnects.<br><br>

Mike</font></body>

</html>