On Wed, 2012-07-18 at 00:34 +0300, Michael S. Tsirkin wrote:

On Tue, Jul 17, 2012 at 02:17:22PM -0700, Nicholas A. Bellinger wrote:

quoted

On Tue, 2012-07-17 at 18:05 +0300, Michael S. Tsirkin wrote:

quoted

On Wed, Jul 11, 2012 at 09:15:00PM +0000, Nicholas A. Bellinger wrote:

quoted

From: Nicholas Bellinger <redacted>

<SNIP>

quoted

I'm happy to commit to working with QEMU + kvm-tool folks to get to a
series that can (eventually) see vhost-scsi support merged into upstream
userspace code.

It took roughly 2 years to get the megasas HBA emulation from Dr. Hannes
merged, but certainly vhost-scsi has alot less moving pieces and
hopefully alot less controversial bits than the buffer -> SGL
conversion..  The key word being here 'hopefully'..  ;)

quoted

I think a good idea for 3.6 would be to make it depend on CONFIG_STAGING.
Then we don't commit to an ABI.
For this, you can add a separate Kconfig and source it from drivers/staging/Kconfig.
Maybe it needs to be in a separate directory drivers/vhost/staging/Kconfig.

So tcm_vhost has been marked as Experimental following virtio-scsi.

Wrt to staging, I'd like to avoid mucking with staging because:

*) The code has been posted for review
*) The code has been converted to use the latest target-core primitives
*) The code does not require cleanups between staging -> merge
*) The code has been stable the last 7 days since RFC-v2 with heavy 

staging is not just for code that needs cleanups.
It's for anything that does not guarantee ABI stability yet.
And I think it's a bit early to guarantee ABI stability - 7 days
is not all that long.

I was talking about the new I/O path has been running for 7 days.

See for example Anthony's comments that raise exactly the ABI
issues.

As mentioned in the response to Anthony, we are using the same generic
fabric ABI in drivers/target/target_core_fabric_configfs.c since .38.

That part is not going to change, and it has not changed for any of the
other 7 target fabric modules we've merged into mainline since then.

quoted

Also, tcm_vhost has been marked as Experimental following virtio-scsi.
I'd much rather leave it at Experimental until we merge upstream
userspace support.   If userspace support never ends up materializing,
I'm fine with dropping it all together.

Once it's in kernel you never know who will use this driver.
Experimental does not mean driver can be dropped, staging does.

Yes, that's the point of being in mainline.  People using the code,
right..?

quoted

However at this point given that there is a 3x performance gap between
virtio-scsi-raw + virtio-scsi+tcm_vhost for random mixed small block
I/O, and we still need the latter to do proper SCSI CDB passthrough for
non TYPE_DISK devices I'm hoping that we can agree on userspace bits
once tcm_vhost is merged.

--nab

I do think upstream kernel would help you nail userspace issues too
but at this point it looks like either staging meterial or 3.6 is too
early.

I think for-3.6 is just the right time for this kernel code.  Seriously,
The basic ABI fabric layout for /sys/kernel/config/target/vhost/ is
going to be the same now for-3.6, the same for-3.7, and the same for .38
code. 

I'd be happy to move tcm_vhost back to drivers/target/ for now, and we
move it to drivers/vhost/ once the userspace bits are worked out..?

Would that be a reasonable compromise to move forward..?

--nab