[ofa-general] [RFP] support for iWARP requirement - active connect side MUST send first FPDU

Tom Tucker tom at opengridcomputing.com
Tue Oct 23 21:16:55 PDT 2007


Michael Krause wrote:
> At 01:17 PM 10/23/2007, Steve Wise wrote:
>
>
>> Sean Hefty wrote:
>>>> 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.
>>> This bug would be better titled "iWarp cannot support uDAPL API". :)
>>> Seriously, the iWarp and uDAPL specs conflict.  One needs to change.
>>>
>>>> Can someone come up with a solution, possibly in iWARP CM, that 
>>>> will work and insure interoperability between iWARP devices?
>>> 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?
>>
>> 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.
>
> 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.
First let me apologize in advance, but that is simply not a workable 
solution for the customer. I'm not taking anything away from the efforts 
of those involved with the definition of the MPA protocol, however, 
unfortunately that protracted debate occurred 2-3 years in advance of a 
deployed solution. The duration of the debate doesn't overcome the 
absence of practical perspective.

There are now multiple implementations, the customers of which are 
complaining about the cost of the compromises made. We now have the 
benefit of hindsight and in my option should rev the MPA protocol. After 
all, that's why the number is there in the header -- right? It may be 
that those involved with the original debate have no interest in 
revisiting it, but IMO that is irrelevant. There are now new companies 
involved that implemented RDDP, have customers using it, and have a 
sustaining (both interpretations intended) interest in making RDDP 
better. I, for one, would encourage them to do so.

Protocols are not immutable, unless they're dead.
>
> 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.
>
Really? What about CRC, Markers and Private Data?
> Mike
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general




More information about the general mailing list