From: Alok Kataria <akataria@vmware.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Dmitry Torokhov <dtor@vmware.com>,
Matthew Wilcox <matthew@wil.cx>,
Roland Dreier <rdreier@cisco.com>,
Bart Van Assche <bvanassche@acm.org>,
Robert Love <robert.w.love@intel.com>,
Randy Dunlap <randy.dunlap@oracle.com>,
Mike Christie <michaelc@cs.wisc.edu>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Rolf Eike Beer <eike-kernel@sf-tec.de>,
Maxime Austruy <maustruy@vmware.com>
Subject: Re: [PATCH] SCSI driver for VMware's virtual HBA.
Date: Tue, 01 Sep 2009 10:41:17 -0700 [thread overview]
Message-ID: <1251826877.16169.141.camel@ank32.eng.vmware.com> (raw)
In-Reply-To: <1251825949.12482.34.camel@mulgrave.site>
On Tue, 2009-09-01 at 10:25 -0700, James Bottomley wrote:
> On Tue, 2009-09-01 at 09:59 -0700, Alok Kataria wrote:
> > On Tue, 2009-09-01 at 09:52 -0700, James Bottomley wrote:
> > > On Tue, 2009-09-01 at 09:33 -0700, Dmitry Torokhov wrote:
> > > > On Tuesday 01 September 2009 09:16:51 am Matthew Wilcox wrote:
> > > > > On Tue, Sep 01, 2009 at 09:12:43AM -0700, Roland Dreier wrote:
> > > > > > I'm not really sure we should be trying to force drivers to share just
> > > > > > because they are paravirtualized -- if there is real commonality, then
> > > > > > sure put it in common code, but different hypervisors are probably as
> > > > > > different as different hardware.
> > > > >
> > > > > I really disagree. This kind of virtualised drivers are pretty much
> > > > > communication protocols, and not hardware. As such, why design a new one?
> > > > > If there's an infelicity in the ibmvscsi protocol, it makes sense to
> > > > > design a new one. But being different for the sake of being different
> > > > > is just a way to generate a huge amount of make-work.
> > > > >
> > > >
> > > > The same thing can be said about pretty much anything. We don't have
> > > > single SCSI, network, etc driver handling every devices in their
> > > > respective class, I don't see why it would be different here.
> > > > A hypervisor presents the same interface to the guest OS (whether
> > > > it is Linux, Solaris or another OS) much like a piece of silicone
> > > > does and it may very well be different form other hypervisors.
> > >
> > > Nobody said you had to have the exact same driver for every hypervisor.
> > > What people are suggesting is that we look at commonalities in the
> > > interfaces both from a control plane point of view (transport class) and
> > > from a code sharing point of view (libscsivirt). However, all the
> > > hypervisor interfaces I've seen are basically DMA rings ... they really
> > > do seem to be very similar across hypervisors, so it does seem there
> > > could be a lot of shared commonality. I'm not going to insist on RDMA
> > > emulation, but perhaps you lot should agree on what a guest to
> > > hypervisor DMA interface looks like.
> >
> > Which is this other hypervisor driver that you are talking about,
> > ibmvscsi is using RDMA emulation and I don't think you mean that.
>
> 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.
Also regarding Xen and KVM I think they are using the xenbus/vbus
interface, which is quite different than what we do here.
>
> > 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.
Thanks,
Alok
>
> The benefit to users would be a common control plane and interface from
> the transport class, plus common code means more testers regardless of
> virtualisation technology chosen.
>
> James
>
>
next prev parent reply other threads:[~2009-09-01 17:41 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-27 23:17 [PATCH] SCSI driver for VMware's virtual HBA Alok Kataria
2009-08-28 6:03 ` Rolf Eike Beer
2009-08-31 17:26 ` Alok Kataria
2009-08-31 18:51 ` Rolf Eike Beer
2009-08-31 21:54 ` Alok Kataria
2009-08-28 21:18 ` Chetan.Loke
2009-08-28 22:30 ` Alok Kataria
2009-08-29 12:04 ` Chetan.Loke
2009-08-31 22:35 ` Alok Kataria
2009-08-31 17:28 ` Alok Kataria
2009-08-31 18:00 ` James Bottomley
2009-08-31 21:53 ` Alok Kataria
2009-09-01 14:23 ` James Bottomley
2009-09-01 16:08 ` Alok Kataria
2009-09-01 16:13 ` Matthew Wilcox
2009-09-01 16:20 ` Boaz Harrosh
2009-09-01 16:47 ` Alok Kataria
2009-09-01 14:26 ` James Bottomley
2009-09-01 11:12 ` Bart Van Assche
2009-09-01 14:17 ` James Bottomley
2009-09-01 16:12 ` Roland Dreier
2009-09-01 16:16 ` Matthew Wilcox
2009-09-01 16:33 ` Dmitry Torokhov
2009-09-01 16:52 ` James Bottomley
2009-09-01 16:59 ` Alok Kataria
2009-09-01 17:25 ` James Bottomley
2009-09-01 17:41 ` Alok Kataria [this message]
2009-09-01 18:15 ` James Bottomley
2009-09-02 2:55 ` Alok Kataria
2009-09-02 15:06 ` James Bottomley
2009-09-02 17:16 ` Alok Kataria
2009-09-03 20:03 ` James Bottomley
2009-09-03 20:31 ` Dmitry Torokhov
2009-09-03 21:21 ` Ric Wheeler
2009-09-03 21:41 ` Dmitry Torokhov
2009-09-04 3:28 ` Alok Kataria
2009-09-01 17:25 ` Roland Dreier
2009-09-01 17:40 ` James Bottomley
2009-09-01 17:54 ` Alok Kataria
2009-09-01 18:38 ` Christoph Hellwig
2009-09-02 9:50 ` Bart Van Assche
2009-09-01 16:34 ` Bart Van Assche
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1251826877.16169.141.camel@ank32.eng.vmware.com \
--to=akataria@vmware.com \
--cc=James.Bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bvanassche@acm.org \
--cc=dtor@vmware.com \
--cc=eike-kernel@sf-tec.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=maustruy@vmware.com \
--cc=michaelc@cs.wisc.edu \
--cc=randy.dunlap@oracle.com \
--cc=rdreier@cisco.com \
--cc=robert.w.love@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox