On Mon, 2011-02-14 at 18:46 +0900, FUJITA Tomonori wrote: > On Mon, 14 Feb 2011 01:27:48 -0800 > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > > > On Mon, 2011-02-14 at 18:29 +0900, FUJITA Tomonori wrote: > > > On Mon, 14 Feb 2011 01:01:12 -0800 > > > "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx> wrote: > > > > > > > > btw, can we kill the non scatter/gather data path? I think that we > > > > > should always use the scatter/gather data transfer. > > > > > > > > Unfortuately it's not that easy. The main reason why CDB type > > > > SCF_SCSI_CONTROL_NONSG_IO_CDB was originally added (back in 2.2/2.4 > > > > days) was because certain LLDs had a problem with basic control CDBs > > > > using SGLs.. > > > > > > > > Obviously we are way past that point with drivers/scsi today, but the > > > > main reason today why SCF_SCSI_CONTROL_NONSG_IO_CDB still exists is > > > > because of CDB emulation for complex stuff in target_core_cdb.c. It has > > > > historically proven much easier to code complex CDB emulation using a > > > > contigious buffer, than with walking SGL formatted memory. > > > > > > > > Converting over the more complex CDB emulation stuff to SGLs would > > > > somewhat painful, at least without adding an extra location allocation + > > > > copy into SGLs (not a big deal for CONTROL CDB stuff), > > > > > > lib/scatterlist.c provides nice helper functions to copy data between > > > a linear buffer and an SG list. I think that at least, it's more clear > > > than now. > > > > > > > Yeah, I think this is going to make the most sense for a proper long > > term conversion and removal of SCF_SCSI_CONTROL_NONSG_IO_CDB. > > Ok, I take care of this. > > Great, I will await your patches for this particular item.. ;) > > > Hmm, I don't think that very large contiguous buffer for CONTROL CDB > > > so why can't we allocate a physically contiguous buffer for it? > > > > > > > Well, that depends what you consider large.. ;) > > 2 pages is enough for most? REPORT_LUNS might need a large buffer but > I don't think it's so difficult to handle REPORT_LUNS with > scatter/gather. With existing target_core_cdb.c code I can't really think of a typical case that would go beyond a 2 page (8192 bytes min) range, unless we are talking about returning a large number registrations with PRIN READ_FULL_STATUS or relative target port identifers in MI_REPORT_TARGET_PGS response payload. --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
