On 05/06/2011 02:31 PM, Stefan Hajnoczi wrote:
Okay, this explains how you plan to handle targets appearing - you want to set a maximum number of targets. I was wondering how we would add virtqueues dynamically (and why the control vqs are placed last at n,n+1 instead of 0,1).
You don't, it's not in the spec. On the other hand, I don't think a limit on the number of targets is imposing, and the limit that virtio places is more theoretical than practical.
(Control virtqueues are last simply to avoid +2 and -2 all over the place).
I'm really not sure I understand the win of creating lots of virtqueues. I just want a pipe out onto the SCSI bus so I can talk to all devices in the SCSI domain. Creating separate virtqueues increases complexity in the driver and emulation IMO.
In the driver, probably. Emulation shouldn't change much, there's so little to do in the end in a PV HBA emulation if you have a proper SCSI subsystem and the protocol is a simple transport or reasonably close.
What is the MSI-X win you mentioned? I guess if an application on vcpu0 is accessing target0 a lot then interrupt handling can be handled on vcpu0 while other vcpus handle interrupts for other SCSI targets?
Yes, possibly. But I think the main benefit is in resiliency. If one target malfunctions and timeouts, other targets still work normally until the SCSI layer decides to reset that target.
I remember VMware pv scsi has a trick here, each request can contain the vcpu number which influences interrupt routing somehow.
I don't think it works under Linux though, it depends on how the OS sets up the APICs.
Paolo
