Dexuan,

Regarding this patch, I'm not sure if it's a "workaround": if it's
incorrect to set a bigger-than-SHRT_MAX scsi_driver.can_queue value,
probably we should change scsi_driver.can_queue from "int" to "u16"?

BTW, I guess the "cmd_per_lun" should also be "u16" rather than
"short"?

I agree that it would be nice to get all this cleaned up. Several,
somewhat peculiar, 25-year old design choices.

cmd_per_lun has traditionally been in the ballpark of low hundreds,
can_queue typically in the low thousands. And the block layer currently
caps at ~10K. Happy to take patches fixing this up, although I am a bit
worried about how much churn it will generate.

That said, I do think that cleaning this up is somewhat orthogonal to
the issue with storvsc. I suspect that allowing a huge amount of
concurrent outstanding commands is going to be detrimental to
performance for most workloads. And from that perspective I think that
the short->int fix, while valid given the type discrepancy, is just
treating the symptom.

Therefore I consider the short->int fix a workaround. And the proper fix
involves looking closely at things are scaled in the storvsc case. Which
I have noted that Michael is working on.

-- 
Martin K. Petersen	Oracle Linux Engineering