Re: [RFC-v2 0/4] tcm_vhost+cmwq fabric driver code for-3.6

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> > On Tue, 2012-07-17 at 18:05 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Jul 11, 2012 at 09:15:00PM +0000, Nicholas A. Bellinger wrote:
> > > > From: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx>

<SNIP>

> > 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'..  ;)
> > 
> > > 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.

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

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

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux