Re: [Qemu-devel] scsi-generic and max request size

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2010-12-22 at 14:54 +0100, Hannes Reinecke wrote:

> Well, sort of. 'sg' doesn't have any block queue limits directly as the
> block queue is attached to the block device (surprise, surprise :-).
> But nevertheless any commands send via SG_IO are being placed on the
> block queue, hence the same limits apply here, too.

Right, tho is there a "simple" way to map sg to the appropriate block
driver to retreive the info via sysfs ? I looks possible from a quick
peek there but it also looks like an ungodly mess.
 
> If it were me I would be using

I think you meant to type more here :-)

> > However, I can't quite figure out how to reliably obtain that
> > information in my driver since on one hand, the ioctl doesn't seem to
> > work in mixed 32/64-bit environments, and on the other hand, sysfs
> > doesn't seem to have anything for "sg" in /sys/class/block... Besides,
> > those are both Linux-isms... so we'd have to be extra careful there too.
> > 
> Yes. I've been bashing my head against this, too.

Christoph, any suggestion there ?

> IMO the whole problem arises from the fact that we're deliberately
> destroying information here.
> Most modern HBAs are using separate codepaths for streaming/block I/O
> anyway, but when using 'scsi-generic' we are forced to discard this
> information. We have to fake a SCSI READ/WRITE command, and send it via
> SG_IO to the underlying device and keep fingers crossed that we're not
> exceeding any device limitations.

I wouldn't say it like that no.

It's a transport problem. In my case I'm not "faking" anything, vscsi is
just a transport (a variant of SRP). The problem is that when
'emulating' a HW HBA, you have no way to express the intrinsic
limitations of the underlying HBA, but that's not a problem I have with
vscsi which is meant to be a transport and as such does have means to
convey that sort of information (tho in my case, I have some issues due
to assumptions/bugs in the existing ibm vscsi client driver but that's a
different topic).

So I think there's a significant difference here between emulating a HW
HBA and doing something like vscsi. The former has problems that cannot
be easily solved I believe. The later problems on the other hands can be
solved, the means to do so are there, but we have to deal with
"interface" issues ... plumbing problems.

The non working compat ioctl is one, the fact that "sg" has
no /sys/class/block (or /sys/block) entries is another, etc... Ie, we
are faced with a problem with Linux not exposing those informations in
an easy to retrieve way, and no proper cross-platform way to obtain
those informations neither.

> The whole problem would just go away if we could use the standard block
> read()/write() calls here. Then the iovec would be placed _as
> scatter-gather list_ on the request-queue and the block layer would take
> care of the whole issue.

That would be somewhat cheating with the concept of just being a SCSI
transport layer :-) You would interpret some requests and turn them into
something else. That would be "interesting" when your user starts using
tags and make assumptions about what's in flight and what not etc...

> I've tried to advocate this approach once, but (again) was being told
> that it's a misuse of scsi-generic and I should be using scsi-disk instead.
> 
> However, since Alex Graf is facing similar problems with the AHCI HBA of
> his maybe we could retry again ...

Again, I'd say different problems :-) To some extent scsi-disk will
solve the issues with basic read/write operations, but there's some more
nasty SCSI commands that you want through for things like DVD burning
for example, unless we start building higher level abstractions into the
kernel. So you -still- end up acting somewhat as a SCSI transport layer,
and potentially hit the problem with limits again.

Cheers,
Ben.

> Cheers,
> 
> Hannes
> --
> Dr. Hannes Reinecke		      zSeries & Storage
> hare@suse.de			      +49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Markus Rex, HRB 16746 (AG Nürnberg)