[Stgt-devel] Re: [PATCH 0/3] ibmvscsis scsi target

[FUJITA Tomonori]

From: FUJITA Tomonori <fujita.tomonori at lab.ntt.co.jp>
Subject: [Stgt-devel] Re: [PATCH 0/3] ibmvscsis scsi target
Date: Tue, 18 Oct 2005 23:14:37 +0900

> > The only other significant comment generated by the the RFC was from
> > Christoph, and requested that this work be combined with the sgtg work
> > that Mike Christie and Tomonori Fujita are working on.  I definitely
> > will start contributing to that work, and will convert this driver to
> > their framework when it becomes complete.  I would rather not keep
> > this driver out of mainline for the amount of time that may take.
> 
> I started to convert ibmvscsi code to the tgt framework a little while
> ago. Its model is pretty different from the iSCSI and FC models so I'm
> trying to figure out what changes we need.
> 
> Hopefully, I will commit the initial code to the repository by the end
> of the month.

I managed to make a SCSI client boot by using the new VIO SCSI target
driver. I uploaded a patch against r119 of the framework code.

http://zaal.org/tgt/ibmvstgt.diff

It includes verbose debug code and makeshift code so I've not
committed it. I'll clean up and commit it next week. I've found some
bugs in the framework during rewriting the driver, however, I've not
fixed them yet.

The code has been not tested heavily, still unstable, and not
finished. In addition, there's no document about how to use the tgt
framework. But it gives a hints how the ibmvscsi driver work with the
tgt framework.

Now I'll go back to the framework and iSCSI software target
code. Maybe I'll do more work on this driver after they become
mature, though I cannot access a POWER machine now. A fellow worker
permitted me to use his machine for the last few days.


There are some key differences between the original driver and my
driver (and I would like to discuss how to deal with them).


o sysfs configuration has gone

The tgt framework provides 'tgtadm' program, which is a universal
target management interface. It uses netlink for kernel/user
communication.

The drivers in the tgt framework (like ibmvscsi, iSCSI software
target, and some FC and iSCSI HBA drivers) can implement
driver-specific features by using dynamic link libraries. That is,
tgtadm uses dlopen, dlsym, etc internally.


o No cache management for rdma

First, my driver does not manage viosrp_iu cache and simply uses
mempool for it. So every time dma_map_single is called.

Second, my driver does not manage data buffer cache so it calls
dma_map_sg() to map pages in sg every time.

I'm not sure about how it hurts performance. If it does hugely, we
need new tricks in the tgt framework.


o no continuous data buffer

The tgt framework allocates pages in sg for data buffer. They are not
continuous unlike data buffer in the original driver. So my driver
needs to do rdma more times than the original driver. However, single
iue_entry can handle very long data buffer so my driver is simple
because it does not slitted ius.


I think there are more, however, I need to go to bed because I'll fly
early tomorrow morning to attend (or crash) my friend's wedding. I'll
be back on Monday.