On 11/23/2015 05:18 PM, Bart Van Assche wrote: > > > On 11/23/2015 08:10 AM, Hannes Reinecke wrote: >> On 11/20/2015 11:58 PM, Bart Van Assche wrote: [ .. ] >>> BTW, not all storage arrays need STPG retries. Some arrays are able >>> to process an STPG command quickly (this means within a few >>> seconds). >>> >>> A previous discussion about this topic is available e.g. at >>> http://thread.gmane.org/gmane.linux.scsi/105340/focus=105601. >>> >> Well, one could argue that the whole point of this patchset is to >> allow you to serialize STPGs :-) >> >> We definitely need to serialize STPGs for the same target port >> group; the current implementation is far too limited to take that >> into account. >> >> But the main problem I'm facing with the current implementation is >> that we cannot handle retries. An RTPG or an STPG might fail, at >> which point we need to re-run RTPG to figure out the current status. >> (We also need to send RTPGs when we receive an "ALUA state changed" >> UA, but that's slightly beside the point). >> The retry cannot be send directly, as we're evaluating the status >> from end_io context. So to instantiate a retry we need to move it >> over to a workqueue. >> >> Or, at least, that's the solution I'm able to come up with. >> If you have other ideas it'd be most welcome. > > Hello Hannes, > > I agree that retries have to be handled from workqueue context > instead of end_io context. But in workqueue context we can choose > whether to submit the retry synchronously or asynchronously. Unless > I overlooked something I don't see why the retry should be submitted > synchronously. > Good point. Sure we can do this; the primary difference would be whether the workqueue is ordered or not. An unordered workqueue would be resulting in not serializing retries, hence achieving pretty much what you asked. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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
