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. 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). 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? - R. -- 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
