Re: Ang: Re: [Stgt-devel] Re: [Iscsitarget-devel] stgt a new version of iscsi target?

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

 



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

Here are some performance results with open-iscsi (which are better
than the previous results that I got with sfnet).

o IET

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