Greetings Ming!
On Tue, 2008-05-20 at 08:33 -0400, Ming Zhang wrote:
> Hi
>
> See if you can shed a light on this.
>
> When use the target for exporting a local scsi device to iscsi
> initiator, there is a issue here. linux has a max_hw_sector for each
> device and iscsi ini side have another number. if ini thought this
> device can handle large request, it will send a large request size, then
> how target deal with it?
The target mode engine really has to handle this IMHO. This ended up
being a requirement for me personally around LIO-Target v1.8 with
megaraid SATA using max_sectors == 128 * 512 Byte sectors (for handling
smaller HW RAID stripe sizes) and Host OS SCSI subsystems on the iSCSI
Initiator side assuming max_sectors == 256 * 512 Byte sectors as default
(and some OSes not having an easy way to change that..)
The method in which LIO-Target Core achieves this for
ICF_SCSI_DATA_SG_IO_CDB is by the se_mem_t linked list memory allocation
logic (used in iscsi_target_transport.c) and Received Initiator CDB
(single CMD) vs. CDB(s) going into LIO Subsystem API (N number of
TASKs). This design allows for:
1) Any combination of the received CMD's CDB count, and max_hw_sectors a
+ sector_size (if the latter is not legacy 512 Byte sectors) up to the
allowed CmdSN Window depth for a given Initiator Port <-> Target Port
iSCSI Nexus.
2) That said LIO se_mem_t memory, which has been using se_mem_t->page in
v2.9, (no changes to v3.0 just yet for this to become completely >= k.o
v2.6.24 struct scatterlist->page_link modern :) can be either
a) Allocated as the engine receives traditional iSCSI
PDUs during traditional socket level I/O.
b) Allocated during LIO target engine passthrough by caller.
c) That incoming memory into LIO-Core can be preregistered
beforehand and ready direct data placement memory buffers
(using HW or SW RNICs drivers) can be mapped with all of the
above requirements.
This model allows for multiple types of SCSI device types, both physical
and virtual from different storage subsystems, and obviously you still
need to emulate the control bits, which are going to be emulated per
SCSI transport specific, yes..?
--nab
>
>
--
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
