On Tue, Nov 29, 2011 at 11:27:13PM -0800, Nicholas A. Bellinger wrote: > So I'm still undecided if pushing this completely out into fabric > drivers in order to drop the current complexity of queue full with > target-core is a better tradeoff for not.. > > This type of core internal queue-full handling is used by ib_srpt and > other fabrics potentially using ACK_KREF, so I think we want to at least > still handle generically for fabrics (if necessary) that need it atm. How exactly do they use it? Note that we really can't do better than the dumb busy waiting done now in the core code. The ressources generally are per-hba, and without introducing a huge mess of methods for waiting and wakeups it's impossible to get this right outside the drivers. Now that we use workqueues for the submission and completion pathes blocing inside ->queue_data_in and ->queue_status isn't a problem, and all these issues can be fixed pretty trivially by adding a waitqueue in the driver. > > + } > > + > > + return error; > > } > > EXPORT_SYMBOL(qla_tgt_xmit_response); > > > > Note outgoing TFO->write_pending() -> qla_tgt_rdy_to_xfer() failures > will also need to be addressed for this to work as expected for FCP > WRITE. Indeed. But it's just another waiter on the waitqueue. What's more important is finding out where it should be woken. Given that you wrote the initial code - what is the actual resource the we run out of, and where does it get used/released? That is the kind of comment much more important in code than reiterating what is beeing done, btw. -- 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
