On Wed, 2012-03-21 at 17:55 -0700, Roland Dreier wrote: > On Wed, Mar 21, 2012 at 5:47 PM, Nicholas A. Bellinger > <nab@xxxxxxxxxxxxxxx> wrote: > > For > 1 task operation in transport_allocate_data_tasks(), the > > transport_do_task_sg_chain() is still required (along with an extra SGL > > per se_task->task_sg[] for the link) in order for a se_cmd's SGLs to be > > made into a single walkable list using scatterlist.h primitives. > > OK, that's the part I don't understand. It seems like > transport_allocate_data_tasks() will always make the individual > task_sg by taking apart the cmd_sg that's passed in, and that's the > only place that I can see where we create multiple tasks for a single > cmd. So why do we need to splice the task_sgs back together, when we > have the original cmd_sg in one piece from the beginning? > To clarify, in >= v3.1 kernel code these are no longer strictly necessary for fabrics who already use se_cmd->t_data_sg directly, as long as the PAGE_SIZE max_sectors alignment is working as expected. Using a list built from (multiple) se_task->task_sg[] and containing the SGLs for what is actually being dispatched to the backends does seem a little safer, but then again the original reasoning for doing this was so HW fabrics could have a single walkable list for use with pci_map_sg() & friends before the target-core conversion of se_mem -> scatterlist. Note tfc_io.c:ft_queue_data_in() and ft_recv_write_data() are using se_cmd->t_data_sg directly these days, but still using transport_do_task_sg_chain() for the DDP FCP WRITE offload case. So thinking about this some more, I think it's probably OK to drop transport_do_task_sg_chain() logic once the remaining fabric modules (qla2xxx, ib_srpt, and tcm_fc) are converted to use se_cmd->t_data_sg. --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
