On Wed, 2011-10-12 at 11:17 -0400, Christoph Hellwig wrote: > Warning: I'm not actually able to reproduce QUEUE FULL handling locally, > so the actual code path touched here isn't tested. > > If there actually is a good reason for doing the workqueue step in > queue full handling this is obviously not going to fly, but even after > an extensive audit I really can't see anything that requires us to not > call transport_add_cmd_to_queue from the original context. > Mmmmm, i'm still undecided on this one. The thought here is having a workqueue + context switch for a QUEUE FULL event gives the hardware (more) time to make room by clearing entries in it's request/response queues, and by re-adding these immediately would end up generating more QUEUE FULL events. I don't know how much (more) time the HW needs under load to avoid excessive QUEUE FULL events, so i'll probably pass merging this one for the moment until there is a better idea of potential drawbacks here. Also Cc'ing Roland as he hasssome experience with QUEUE FULL with qla2xxx. --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
