[ofa-general] iWARP peer-to-peer revised proposal

[Caitlin Bestler]

On Dec 11, 2007 2:07 PM, Kanevsky, Arkady <Arkady.Kanevsky at netapp.com> wrote:
> Goal is to have something implemented now in IW_CM to solve interop
> issues which we can use as a starting point to submisison to IETF MPA
> "extension".
>
> The proposal is for an initiator side to generate the first message
> (RTU)
> in RDDP mode.
> RTU stands for the 3rd MPA message - Ready to Use.
>
> Initiator side:
> 1. IW_CM sends first MPA message (request).
>
> Option A: no change for MPA request.
> Option B: Steal a bit from reserve field to indicate that Initiator
> "supports" peer-to-peer model and wants to use it.
> The default value is 0 indicating that Initiator does
> not support peer-to-peer model which is the same as current MPA format.
> Value 1 indicates support.
> Option C: The same as option B but steal a bit from private data for it
> instead of reserved field.
>

The key phrase here is "and wants to use it". For most RDMA connections,
and *all* RDMA connections for many ULPs, there is a natural active/initiator
side message that will be immediately or promptly available after connection
establishment. No special unblocking action is required, nor should
one be taken.

An active/initiator ULP that believes it is at risk of not producing a
prompt intiial
message should have an option to so indicate to find out if its remote peer will
let it off the hook to some degree. The two degrees discussed to date
are allowing
use of zero lengh RDMA Reads or RDMA Writes to unblock.

As long as we are clear that this feature is not forced upon the ULP unless the
ULP sees a need for it, I have no problem with any of the proposals. Changes to
the MPA Header, however, should be proposed through the IETF. OFA coming
to a consensus on a proposal is fine, but it should go to the IETF after that. A
convention on use of private data could be reached within OFA alone.


> [For the quick fix Option A is the easiest. For the MPA

>
> 7. For OFA interop lets agree what the RTU message type will be.
> My recommendation is unsignalled 0b Read.
>

I see no problem with OFA interop testing limiting the tested options
to those that interop participants have declared an intention to support.