On Mon, 2012-04-02 at 16:24 -0700, Roland Dreier wrote: > I think this is fine (to me it doesn't make much sense to use > pscsi to pass through a scsi device, except to expect to do > IOs bigger than what the backing device supports). > > To me the more interesting issue is how we handle limits in the > fabric driver. For example the qla2xxx hardware/firmware has > a limit on the number of SG entries in a single transfer (I think > it's somewhere around 1400 or so, which means we could do > ~5+ MB transfers with PAGE_SIZE sglist entries). I expect > other fabric drivers for SCSI hardware will have limits of the > same type. > Indeed. Enforcing this for HW fabrics be a good idea to prevent SCSI CDB lengths from running afoul of per descriptor HW limits. > So currently it is pretty impossible to go over this limit with > the current target core and tcm_qla2xxx fabric driver, since > we have to do the whole command sglist in one go at the > fabric level. > > We could handle bigger commands on top of this hardware -- > we just need to break up the commands into pieces when we > pass them to the fabric (sort of the evil twin of how we split > commands into tasks to pass to the backend). Ouch, that sounds painful to do on a per fabric basis.. > However it > might be more interesting/useful to limit the amount of memory > we allocate for a single command -- for example, if we're going > to only be able to send 4MB at a time, it might be a good idea > not to have much more than that in flight for a single command > (also this would let us someday overlap backend and fabric > transfers, which might help performance in some cases). > > Thoughts? > I'm not aware of client block / SCSI subsystems that are generating individual CDBs larger than 1-2 MB per I/O currently, so it should give enough us breathing room with SGL lengths using PAGE_SIZE for qla2xxx. Using SGLs w/ contiguous physical memory of more than a single page would be a cleaner solution to support large I/Os beyond individual HW SGL entry limitations. Doing 2x contiguous page allocation per SGL entry at run-time is one option, or some type of pre-allocation of larger contiguous memory regions to be used by HW SGL entries. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
