Re: [virtio-comment] [PATCH 2/5] virtio-blk spec: writeback cache enable improvements

[James Bottomley <jbottomley@parallels.com>]

On Mon, 2013-08-19 at 17:47 +0200, Paolo Bonzini wrote:
> Il 19/08/2013 17:31, James Bottomley ha scritto:
> > Well, yes, effectively.  You only have two implemented VIRTIO drivers:
> > virtio-scsi and virtio-blk, both of which emulate packet transport
> > protocols.  Block is much more problematic because it's not really
> > designed to be a wire protocol unlike SCSI.
> 
> SCSI is an RPC protocol, but the wire protocol is obviously left to the
> transport.

I don't understand your point here:  If you think the transports modify
the commands, that's not correct.  The job of the transport is to get
the command from initiator to target ... it's just that, a transport
layer; exactly like RPC or TCP.

>   So in this respect block and SCSI aren't really like night
> and day.

This is what I don't get.  They could both be implemented as transport
encapsulations of an existing command set.

>   The difference is that the SCSI RPC is very small, and the
> complicated/evolving parts are at a different level, so the host and
> guest code that implements the virtio-scsi spec is very small.

> Those complicated/evolving parts are _still_ there, so the code needed
> in the host to implement virtio-scsi is indeed much larger than
> virtio-blk.  But it's a non-issue for a non-toy VMM because that code is
> needed anyway, for example to support USB storage.

It might be now, but once you've done the feature creep in the
virtio-blk spec to support all of our user visible features (DIF,
discard, etc.) you'll probably find that the need to translate the
commands causes virtio-blk to grow faster than virtio-scsi.

> And piggybacking on SCSI means that whenever a new feature comes along,
> someone else is already doing the work to integrate into the Linux block
> layer, to use it, to export it to userspace, etc.  This typically
> happens before hosts implement the feature, so us virt people get a
> large part of the work for free; we only need to implement the feature
> in the host, because these feature rarely if ever affect the SCSI RPC
> interface.  Instead, adding the smallest feature to virtio-blk always
> necessitates updates to both the spec and the guest drivers, in addition
> to the VMM (typically QEMU).

Spec, possibly, since someone needs to be told about commands added to
block, but it shouldn't need modification of correctly implemented
drivers.  If the encapsulation were done right, the client would just
send the correct commands, so no code growth.  Implementing them as a
pass through is a nop as well, so the only problem case is non-native
and there, you'll find the code growth is just slightly less than what
you have abstracting all the commands.

> This is not hypothetical, it has already happened for discard and it
> will happen sometime for write-zeroes.
> 
> > However, what you should be
> > doing is mirroring the REQ_ protocol and have a side handshake to set
> > the capability flags.  That will ensure that all block features just
> > work (tm) in the same way.
> 
> That's roughly what virtio-blk does (though it was not kept up-to-date
> with discard and write-zeroes).

But this is illustrative of the point.  When the block layer is patched
to add more stuff (which has been happening quite a lot lately), you
have to rev your spec and update all the guest and host drivers.  This
is one of the reasons for the current SCSI architecture model: not to
have to do this.

> > For standards purposes, I'm not really sure
> > how to proceed on this but I believe linux will be the only implementor
> > of virtio-blk, right, so it probably doesn't matter.
> 
> There are Windows drivers for virtio-blk.

Which are thus effectively emulator drivers.

James