Re: [PATCH v2 10/11] megaraid_sas: Use Block layer API to check SCSI device in-flight IO requests

[John Garry <john.garry@huawei.com>]

>>
>> OK, I have a rough idea of the concept. And again I'd say megaraid sas
>> may not be a good candidate to expose > 1 HW queues, as we hide HW
>> queues and don't maintain the symmetry with blk-mq layer.
> Sorry, my last response was not very clear. I was referring to reply
> queues as HW queues
> not submission queues. I agree with you, since megaraid_sas HW has
> single submission
> queue so >1 HW queue would not help to improve performance. Testing
> done by us on shared
> tagset patches worked by you/Hannes was to ensure no performance drop
> from single HW
> submission queue based driver.

OK, but I still have concern with this. That's your choice.

>>
>> Indeed, I do not even expect a performance increase in exposing > 1 HW
>> queues since the driver already uses the reply map + managed interrupts.
>>
>> The main reason for that change in some drivers - apart from losing the
>> duplicated ugliness of the reply map - is to leverage the blk-mq feature
>> to drain a hctx for CPU hotplug [0] - is this something which megaraid
>> sas is vulnerable to and would benefit from?
> "megaraid_sas" driver would be benefited with draining of IO
> completions directed to
> hotplugged(offlined) CPU. With current driver IO completion would
> hang, if CPU on which IO is to be
> completed goes offline.

But that feature will only work for the queues which you expose. For the 
low-latency queues, there would be no draining*. However, the 
low-latency interrupts are not managed; as such, I think that their 
interrupts would migrate when their cpumask goes offline, rather than 
being shutdown, so not vulnerable to this problem.

* In principle, since you can submit the scsi request on different hw 
queue than expected from blk-mq perspective, when we offline the cpu 
which blk-mq set to submit on, blk-mq may actually wait for requests to 
complete on these low-latency queues and addition to the HW queue which 
blk-mq thought that the request would be submitted on - again, not 
ideal, and may cause problems.

Thanks,
John