>> Therefore, the only truly safe thing for an iWARP btl to do (or a
>> udapl btl since that is also an iWARP btl) is to have the active
>> layer send an MPI Layer "nop" of some kind immediately after
>> establishing the connection if there is nothing else to send.
> This is fine for an iWARP/RDMACM/whatever BTL (or anything
> else that uses the OFA verbs interface(s)), but my argument
> is that uDAPL is NOT specifically there to support just iWARP
> (though it may include it), and that OFED's uDAPL should be
> adjusted to handle this. Again, uDAPL is a network
> *independent* abstraction, so requiring network-dependent
> behavior from the uDAPL consumer is wrong.
DAPL strives to define network independent solutions. In this
case the network independent solution is that the active side
*always* sends the first message. This works for both iWARP
and InfiniBand. And away from the HPC market it is almost a
non-requirement (which is why the RDMAC managed to goof on
this in its specification. A zero-length RDMA Write is enough
to deal with the wire protocol problem, but people implemented
to the RDMAC verbs.)
> A related question -- how does this 'connection initiator
> must send first' requirement relate to UD?
iWARP UD is called UDP. It has nothing to do with MPA
or RDMA. An API that mapped to either IB UD or UDP is
definitely feasible, but hasn't been important enough
to anyone to draft as of yet.