Jeremy Linton wrote: > On Wednesday 06 December 2006 17:42, Jeremy Linton wrote: >> On Wednesday 06 December 2006 16:50, Mike Christie wrote: >>>> For iscsi, we could negotiate a value like MaxBurstLength which says >>>> don't send commands with a payload larger than that size. I would guess >>>> other transports have something similar. We have to check or make sure >> ... >> >>> Oh yeah the exception I am thinking about may not be max sectors exactly >>> but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs >>> are supposed to be translating that iscsi limit to max_sectors in which >>> case we are talking about the same thing. For this limit we do not want >> Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max >> transfer size, it simply is the amount of data that can be sent without a >> R2T. If the transfer is larger then you have to wait for the R2T. In >> practice it ends up controlling the _minimum_ amount of buffer space that >> needs to be available _before_ the transfer starts, otherwise performace >> sucks. > Whops, Slight clarification, the MaxBurstLength is the max sent between R2T's > what I described above is closer to the FirstBurstLength. What you guys are I should have clarified this would have been a workaround for some bad targets, but I hoped could be more useful for other transports that needed it for valid reasons. The MaxBurstLength length limits what can be transferred in sequence of data-in pdus _or_ like you describe a solicited data out sequence, doesn't it (see section 12.13)? We are more concerned with the data-in sequence here. If we have a READ of 1048576 bytes and a MaxBurstLength=524288 some targets were getting confused and instead of splitting up the transfer into multiple sequences it would assume there could be one sequence. So for those targets the MaxBurstLength becomes the max we can read and targets do fun things like drop connections if we send them something larger. Oh the flip side, targets also end up sending us more than MaxBurstLength bytes between r2ts. The initiator just prints an error and makes sure it does not go out of bounds because this is so common. We have to handle lots of fun bugs in targets. I bet targets do lots of weird things to handle our mess ups too :) And a sequence does not necessarily mean one pdu so MaxRecvDataSegmentLength does not matter in the discussion of max request size here (as long as we are talking about good behaving targets :)). Sorry for the confusion. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
