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

[Arlin Davis]

Sean Hefty wrote:
>> I said "clean way to do it". ;-)
> 
> I'm referring to an rdma cm connection protocol for iWarp.  We have one 
> for IB.  I mentioned uDAPL as a possibility because it abstracts the 
> transport, QP, CQ, etc. anyway, and one could argue that the uDAPL iWarp 
> provider should take necessary steps to support the uDAPL API.

There is one OpenFabrics uDAPL provider for all OFA devices. Sure, we 
could add some logic in the DAPL abstraction layer to check for iWARP 
devices and possibly hide the restriction. Say we do that, what about 
the applications that sit directly on top of OFA verbs and rdma_cm? Say 
we add some iWARP abstraction at this layer, what about the WinOF stack?

> 
> I don't know that there's a need to change the iWarp architecture.

If you think customers are willing to work around this restriction then 
by all means leave the architecture alone and simply document the rdma 
API's. I would think that this put's iWARP vendors at a disadvantage.

I am guessing that energy and time spent changing the iWARP protocol 
specification is a better use of everyone's time then hacking every 
iWARP stack out there to hide the restriction.

-arlin