Re: [PATCH] SCSI driver for VMware's virtual HBA.

[James Bottomley <James.Bottomley@suse.de>]

On Tue, 2009-09-01 at 10:41 -0700, Alok Kataria wrote:
> > lguest uses the sg_ring abstraction.  Xen and KVM were certainly looking
> > at this too.
> 
> I don't see the sg_ring abstraction that you are talking about. Can you
> please give me some pointers. 

it's in drivers/lguest ... apparently it's vring now and the code is in
driver/virtio

> Also regarding Xen and KVM I think they are using the xenbus/vbus
> interface, which is quite different than what we do here. 

Not sure about Xen ... KVM uses virtio above.

> > 
> > > And anyways how large is the DMA code that we are worrying about here ?
> > > Only about 300-400 LOC ? I don't think we might want to over-design for
> > > such small gains.
> > 
> > So even if you have different DMA code, the remaining thousand or so
> > lines would be in common.  That's a worthwhile improvement.
> 
> And not just that, different HV-vendors can have different features,
> like say XYZ can come up tomorrow and implement the multiple rings
> interface so the feature set doesn't remain common and we will have less
> code to share in the not so distant future.

Multiple rings is really just a multiqueue abstraction.  That's fine,
but it needs a standard multiqueue control plane.

The desire to one up the competition by adding a new whiz bang feature
to which you code a special interface is very common in the storage
industry.  The counter pressure is that consumers really like these
things standardised.  That's what the transport class abstraction is all
about.

We also seem to be off on a tangent about hypervisor interfaces.  I'm
actually more interested in the utility of an SRP abstraction or at
least something SAM based.  It seems that in your driver you don't quite
do the task management functions as SAM requests, but do them over your
own protocol abstractions.

James