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

[Christoph Hellwig <hch@lst.de>]

On Tue, May 31, 2011 at 02:32:47AM -0700, Nicholas A. Bellinger wrote:
> As Christoph mentioned earler, this original patch to enable your
> iscsi-target optimization series breaks all non iscsi-target fabrics.
> But hey, that is easy enough for me to fix now.  ;-)

I don't think it breaks all of them.  Besides iscsi only tcm_fc (btw, why did
this one get commited with the stupd tcm prefix that we killed in all other
places?) and SRP use this function.  FC uses the same scheme as iSCSI
and should be fine with the direct call.  SRP has a three callers leading
towards srpt_handle_new_iu, of which two also come from the main handling
thread, and the third comes from an IB layer callback.  I've not looked
over the IB code yet, but it appears to either be fine to do the direct
call here, or easily doable by offloading the IB callback from a higher
level.

Doing this would have the huge advantage of greatly simplifying the
entry points into the command processing - either call transport_new_cmd
directly, or use the thread for the TRANSPORT_NEW_CMD case.  Mid-term
getting rid of that entry point also sounds fine, if we replace the
current main thread with a work queue where frontends can queue their
own items, and use those for deferring things from IRQ context only
when needed.  This would also mean we can remove the new_cmd_map callback.