[stgt] [PATCH 14/15] Fix iSCSI Data-Out solicitation
arne.redlich at googlemail.com
Wed Jun 17 08:46:50 CEST 2009
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
"The Desired Data Transfer Length MUST NOT be 0 and MUST not exceed
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."
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
More information about the stgt