Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?
michaelc at cs.wisc.edu
Sat Dec 31 04:27:29 CET 2005
James Bottomley wrote:
> On Tue, 2005-12-27 at 08:53 +0900, FUJITA Tomonori wrote:
>>Mike and I have worked on the tgt mmap version.
>>o It does read/write commands like sg by using mmap in user space and
>>get_user_pages in kernel space.
>>o It does non-read/write commands like direct I/O by allocating
>>aligned buffers in user space and using get_user_pages in kernel space.
>>It works like the simple tap that you suggested. It does not allocate
>>buffers in kernel space at all and does zero copy on all sorts of
>>Here are some performance results with open-iscsi (which are better
>>than the previous results that I got with sfnet).
>>| 2005/12/27-07:50:59 | STAT | 6827 | v1.2.8 | /dev/sdc | Total write throughput: 53790310.4B/s (51.30MB/s), IOPS 6566.2/s.
>>o current tgt (I/O in kernel space)
>>| 2005/12/27-08:07:50 | STAT | 7294 | v1.2.8 | /dev/sdc | Total write throughput: 49666457.6B/s (47.37MB/s), IOPS 6062.8/s.
>>o tgt mmap
>>| 2005/12/27-08:42:51 | STAT | 5286 | v1.2.8 | /dev/sdc | Total write
>>throughput: 44701286.4B/s (42.63MB/s), IOPS 5456.7/s.
>>We can get something like this if we avoid calling mmap/munmap per
>>command (by using some sorts of caching).
>>o tgt mmap (mmap caching)
>>| 2005/12/27-07:53:19 | STAT | 6996 | v1.2.8 | /dev/sdc | Total write throughput: 48253337.6B/s (46.02MB/s), IOPS 5890.3/s.
>>James, can we get your approval of the this mmap design?
> Yes, that looks fine ... it runs in user space, which was really all I
> was looking for.
> There is another half to this, which is that I'd like the tap to come
> via a SCSI API. This isn't strictly necessary for iSCSI but it would
> allow us to integrate a generic target approach that could work for all
> SCSI HBA's as well as just iSCSI.
The code we currently have is designed to work with software iscsi
targets or software AoE and HW cards like qlogic or emulex's FC cards.
There are a lot of places we could use scsi-ml or block layer structs
like the request or scsi_cmnd.
To support HW like qlogic or emulex's FC target mode, are you thinking
you might want us to add on to the scsi-ml's scsi_host_template or add a
scsi_target_template? If we add on to the scsi_host_template and if that
one PCI device would be in initiator and target mode at the same time
would we have one scsi_host for that resource and just add our target
related fields to the scsi_host? Is this what you mean?
More information about the stgt