On Wed, 2012-03-21 at 16:09 -0700, Roland Dreier wrote: > Hi Nic, > > I'm trying to understand how transport_do_task_sg_chain() is used in > the current stack. I'm not sure if I'm missing something, or if all > this logic can be eliminated. It looks like we always have an sg list > in the se_cmd, and then when we split the command into tasks, we put a > sublist of that sg list into each task. Then all > transport_do_task_sg_chain() does is chain those sublists back > together into a new chained list that AFAICT is equivalent to the > command's original sg list. > > So does it make sense to get rid of this task_sg_chaining logic and > just have the fabrics use commands' sg lists directly, or is there > something deeper here that I'm not seeing? > Hi Roland, So for single task operation, the transport_do_task_sg_chain() logic is not required because sg_chain() is never called with only a single se_task->task_sg[] present per se_cmd. 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. So no, I don't think we can get rid of transport_do_task_sg_chain() logic as it's still a hard requirement for > 1 task operation. --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
