[stgt] [PATCH 14/15] Fix iSCSI Data-Out solicitation

[Arne Redlich]

Am Dienstag, den 16.06.2009, 19:46 -0400 schrieb Pete Wyckoff:
> arne.redlich at googlemail.com wrote on Tue, 16 Jun 2009 16:45 +0200:
> > Am Dienstag, den 16.06.2009, 06:24 -0400 schrieb Pete Wyckoff:
> > > arne.redlich at googlemail.com wrote on Tue, 09 Jun 2009 18:22 +0200:
> > > > Currently the iSCSI driver only solicits MaxXmitDSL(!) bytes with each R2T,
> > > > although it could solicit MaxBurstLength bytes.
> > > 
> > > This fix makes sense.  R2T should ask for a whole burst.
> > > 
> > > > This was introduced with the iSER driver and a RDMA_TRANSFER_SIZE constant to
> > > > limit the size of RDMA transfers. However, MaxBurstLength can and should be
> > > > used for that.
> > > 
> > > But RDMA should not necessarily use MAX_BURST for its data transfer
> > > sizes.  This size is completely controlled by the target and not
> > > even visible to the initiator.  The initiator should not be involved
> > > in the negotiation of the size.
> > 
> > I don't agree. MaxBurstLength is the upper limit for the amount of data
> > an R2T can solicit, so it's also the upper limit for the RDMA read the
> > R2T is translated to. You can certainly request smaller sizes, but
> > soliciting / RDMA reading data sizes > MaxBurstLength is a violation of
> > the iSCSI spec.
> 
> Please search the old stgt-devel list at berlios for
> 
>     Message-ID: <5eb093080708120312i1287f1f7p2fcaed789bf70cc7 at mail.gmail.com>
>     Date: Sun, 12 Aug 2007 12:12:32 +0200
>     From: Alexander Nezhinsky
> 
> In which he says, in part:
> 
> > iSER spec is silent about the granularity of RDMA transfers
> > because it says nothing about the meaning of MaxBurstLength and
> > MaxRecvDataSegmentLength, when applied to the solicited data of
> > a write op, and to the entire data of a read op.
> > 
> > On the other hand, it maps R2T PDUs to RDMA Reads,
> > and Data-IN to RDMA Writes (changing their meaning), but does not
> > require that their sizes must be governed by either
> > MaxBurstLength (for R2Ts) or MaxRecvDataSegmentLength
> > (for Data-INs).
> > 
> > Thus we can interpret them freely, from the formal point of view.
> > Moreover, this does not contradict the spirit of the protocol,
> > which makes all RDMA transfers a target's responsibility.
> 
> I found that a convincing argument and implemented accordingly.
> 
> Your interpretation makes some amount of conceptual sense, but is
> not really correct.  The initiator truly has no interest in the size
> of the RDMA transfers and should not be involved in negotiating an
> upper limit on their lengths.

This wasn't an interpretation as the specs leave absolutely no room for
that, I was just rephrasing them. Here's the verbatim quotes:

RFC 3720 (iSCSI), 10.8.4 (Desired Data Transfer Length and Buffer
Offset):
"The Desired Data Transfer Length MUST NOT be 0 and MUST not exceed
MaxBurstLength."

RFC 5046 (iSER), 7.3.6 (Ready To Transfer (R2T)):
"4. [..] To transform the R2T PDU, the iSER layer at the target: [...]
 d. MUST use the Desired Data Transfer Length from the R2T PDU as the
RDMA Read Message Size of the RDMA Read Request Message."

HTH,
Arne

--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html