|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: ips : Is FirstBurstSize valid when InitialR2T=yes ?Nick, It is currently (12-98) MacRecvDataSegmentLength rather than MaxRecvPDULength. Pat -----Original Message----- From: Martin, Nick [mailto:Nick.Martin@compaq.com] Sent: Wednesday, February 06, 2002 2:06 PM To: Santosh Rao; IPS Reflector Subject: RE: ips : Is FirstBurstSize valid when InitialR2T=yes ? Santosh, One clarification is that MaxRecvPDULength (formerly DataPDULength), FirstBurstSize, and MaxBurstSize limit the size of the data segment or payload portion of the PDU. The header and digests are not counted within these lengths. (Also note that these are now in bytes now all 512 byte chunks.) Their ranges are 512 to (2**24)-1. The upper bound corresponding to the max value which can be expressed in the 24-bit field DataSegmentLength. If the value is 1024, it means 1024 bytes of data, not 1024 minus 48-byte header, minus up to two 4-byte digests. Compute your own overhead before negotiating the value. One may want to make sure all iSCSI PDUs fit within MTU. If the MTU, the overhead of the protocols below iSCSI, and the overhead of iSCSI are known, the number of iSCSI data bytes that will fit in a MTU size packet can be computed and negotiated. It does not need to be a power of 2 nor a multiple of 512. A multiple of 4 is expected. As has been pointed out some values may become unused or meaningless due to the setting of other values. The responder may reply with key=irrelevant. However I see no harm in accepting a numeric value, although it may not be used. The intention of the initiator may be to replace the default value in case part or all of the negotiation for no-unsolicited data is rejected. It is not invalid to have FirstBurstSize less than MaxRecvPDULength and ImmediateData=yes and InitialR2T=no. In this case InitialR2T=no cause no different behavior from InitialR2T=yes, since the FirstBurstSize will always be satisfied with immediate data. I do not think it would be appropriate to reply InitialR2T=Irrelevant. I think key=Irrelevant should be used when the responder is required to reply, but can not construct a reply that makes sense. This could be due to something else making the key meaningless. Examples might be a prior FMarker=no making RFMarkInt=Irrelevant, or a prior AuthMethod=SRP causing CHAP_A=Irrelevant. Key=Reject may fit such cases as well or better, if the other end should already know the prior result. Thanks, Nick > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Tuesday, February 05, 2002 1:56 PM > To: IPS Reflector > Subject: ips : Is FirstBurstSize valid when InitialR2T=yes ? > > > Hello, > > Can someone clarify if the login key FirstBurstSize is valid when : > InitialR2T=yes and ImmediateData=yes ? > > i.e. if immediate data is enabled and un-solicited data is disabled > during login negotiation, is the value of FirstBurstSize > received in the > login response to be interpreted ? > > My current understanding is that FirstBurstSize is inclusive of the > immediate data portion, and so, if immediate data is enabled, but > un-solicited data is disabled, then, FirstBurstSize *must* be > valid and > must be <= DataPDULength. (after rev 09, it would be <= > (MaxRecvPDULength - the header components size)). > > For example, a target implementation may offer a FirstBurstSize < > DataPDULength, in which case, the immediate data size is the > MIN(DataPDULength, FirstBurstSize, bytes_to_send). > > Can someone clarify if this is a correct interpretation or > set me right > on this ? > > Thanks, > Santosh > > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## >
Home Last updated: Fri Jun 14 14:18:42 2002 10820 messages in chronological order |