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

[FUJITA Tomonori]

On Wed, 17 Jun 2009 08:46:50 +0200
Arne Redlich <arne.redlich at googlemail.com> wrote:

> 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."

In iSER case, the Desired Data Transfer Length MUST not exceed WHAT?
--
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