RE: [PATCH v3] scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()

[Dexuan Cui]

> From: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
> Sent: Tuesday, October 12, 2021 2:28 PM
> To: Dexuan Cui <decui@xxxxxxxxxxxxx>
> 
> > 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.

Thanks for the explanation!
 
> 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.

Agreed.
 
> 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.

Agreed. My v1 actually tried to work around the storvsc driver instread. :-)