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." HTH, Arne -- 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