On Mon, 2012-04-02 at 12:18 -0400, Christoph Hellwig wrote: > On Sun, Apr 01, 2012 at 10:11:13PM -0700, Andy Grover wrote: > > On 03/26/2012 02:53 PM, Christoph Hellwig wrote: > > > The high-performance backends (iblock and rd) support tasks of unlimited > > > size. With that there is no reason to keep a complex infrastructure for > > > splitting up commands in place. Stop doing so and only submit a single > > > task per data direction. Once this is in place we can slowly remove fields > > > from the task that duplicate things in the command, or move other fields > > > > Sounds really good to me. What about pscsi and fileio? Do they break > > with unlimited-size tasks? > > For these we still limit the task size - see the hunk in > transport_generic_cmd_sequencer that rejects writes over the backend > limit, and the hunk to make sure we put the minimum of the fabric > and backend limits into the EVPD page. > Hi Christoph, This patch looks reasonable to drop the splitting of uni-directional se_cmd calls into multiple tasks for SCF_SCSI_DATA_SG_IO_CDB. I think the benefit to IBLOCK performance by removing the additional fast-path allocation overhead + SGL mapping to se_task->task_sg[] is now greater than transparently supporting an received CDB I/O length that exceeds what is allowed by backend pSCSI LLD hardware max_sectors, that was originally supported for all backend export cases. This change may effect some users of pSCSI users on legacy hardware, but I think most folks are now using TYPE_DISK struct scsi_device export with IBLOCK. The only other place where this may can issues that cannot be resolved with IBLOCK TYPE_DISK is using TYPE_ROM, TYPE_TAPE or other pSCSI non TYPE_DISK export with an SCSI LLDs using a smaller max_sectors. I'm applying your original patch to lio-core as a v3.5 item, but would still like to figure out a sane way to still support this transparently outside of the IBLOCK fast-path cast for non TYPE_DISK + pSCSI passthrough export. What are your thoughts here..? --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
