Re: [PATCH 39/42] target: Call transport_new_cmd instead of adding to cmd queue

[Christoph Hellwig <hch@lst.de>]

On Fri, Jun 03, 2011 at 07:33:58PM -0700, Nicholas A. Bellinger wrote:
> >  - what is the point of the transport_generic_process_write wrapper?
> 
> Minus the stubbed WRITE overflow copy stuff, this primarly used by
> tcm_loop to queue up the cmd's tasks for execution via
> transport_execute_tasks() instead of a direct fabric module call..
> 
> Currently tcm_loop is the only user of this as we know the full WRITE
> payload is available once the struct scsi_cmd as been dispatched via
> ->queuecommand().

As a first step the stubbed out code really should go away ASAP, it's
really rather confusing as it has little chance to work for the current
code base.  As a follow-on transport_generic_process_write should be
replaced by a direct call to transport_execute_tasks, to make it more
obvious what's going on here.

If we then plan to keep the direct task execution from the submitter
context we should document why we're doing that.  One option would be
to make ->write_pending return a boolean indicator whether we should
call transport_exectute_tasks from
transport_generic_write_pending/transport_generic_new_cmd, and thus
making it more obvious that's it's actually similar to the read path
in that respect.

I'm still not convinced that running the read/write/flush/discard tasks
from the caller is an all that good idea.  They will 100% block for the
file backend, and can block when we reach the request limit with iblock,
and the blocking behaviour might differ for different kinds of requests.