On Wed, 17 Jun 2009 08:46:50 +0200 Arne Redlich <arne.redlich@xxxxxxxxxxxxxx> wrote: > Am Dienstag, den 16.06.2009, 19:46 -0400 schrieb Pete Wyckoff: > > arne.redlich@xxxxxxxxxxxxxx wrote on Tue, 16 Jun 2009 16:45 +0200: > > > Am Dienstag, den 16.06.2009, 06:24 -0400 schrieb Pete Wyckoff: > > > > arne.redlich@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
