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

[Alexander Graf]

On 22.12.2010, at 22:59, Benjamin Herrenschmidt wrote:

> 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.

Why would you care about cross-platform here? Not saying I fully understand 
what information exactly you're lacking. But it's either SG_IO max request size 
in which case you don't need any equivalent on other platforms, as it's not 
available anywhere else. Or it's something else in which case you can just set 
it to some "safe" small default value and call it a day :).


Alex