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. -- 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
