public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Yusupov <dmitry_yus@yahoo.com>
To: "open-iscsi@googlegroups.com" <open-iscsi@googlegroups.com>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux
Date: Sat, 12 Mar 2005 09:08:09 -0800	[thread overview]
Message-ID: <1110647289.16456.6.camel@mylaptop> (raw)
In-Reply-To: <42331EF3.4000806@netapp.com>

On Sat, 2005-03-12 at 11:55 -0500, Dave Wysochanski wrote:
> Alex Aizman wrote:
> 
> >
> > This is to announce Open-iSCSI project: High-Performance iSCSI 
> > Initiator for
> > Linux.
> >
> > MOTIVATION
> > ==========
> >
> > Our initial motivations for the project were: (1) implement the right
> > user/kernel split, and (2) design iSCSI data path for performance. 
> > Recently
> > we added (3): get accepted into the mainline kernel.
> >  
> > As far as user/kernel, the existing iSCSI initiators bloat the kernel 
> > with
> > ever-growing control plane code, including but not limited to: iSCSI
> > discovery, Login (Authentication and Operational), session and connection
> > management, connection-level error processing, iSCSI Text, Nop-Out/In, 
> > Async
> > Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in
> > the user space. This control plane talks to the data plane via well 
> > defined
> > interface over the netlink transport.
> >  
> > (Side note: prior to closing on the netlink we considered: sysfs, 
> > ioctl, and
> > syscall. Because the entire control plane logic resides in the user 
> > space,
> > we needed a real bi-directional transport that could support asynchronous
> > API to transfer iSCSI control PDUs: Login, Logout, Nop-in, Nop-Out, Text,
> > Async Message.
> >
> > Performance.
> > This is the major goal and motivation for this project. As it happens, 
> > iSCSI
> > has to compete with Fibre Channel, which is a more entrenched 
> > technology in
> > the storage space. In addition, the "soft" iSCSI implementation have 
> > to show
> > good results in presence of specialized hardware offloads.
> >
> > Our today's performance numbers are:
> >
> > - 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block
> > size);
> >
> > - 320MB/sec Write on a single connection (2-way 2.4Ghz Opteron, 64KB 
> > block
> > size);
> >
> > - 50,000 Read IOPS on a single connection (2-way 2.4Ghz Opteron, 4KB 
> > block
> > size).
> >
> Has anyone on the list verified these #'s? 

as far I know, no one tried that but me. We've used disktest with
O_DIRECT flag set on 10Gbps network with jumbo frames enabled and big
big big TCP window & socket buffer. I really would like to see that this
number gets reproduced not on my setup only.

>  I'm trying to
> get open-iscsi to work but it looks like it's got a problem
> in the very initial stages of lun scanning that prevents
> my target from working.  Open-iscsi guys I have a trace
> if you want to look at it.  Looks like despite the fact that
> report luns is returned successfully and only 1 lun is
> returned (lun 0), the initiator is still sending inquiry
> commands to luns > 0, and it looks like it gets confused
> when it gets a 0x3f inquiry response from the target
> (for an inquiry to lun 1), tries to issue a TMF abort
> task on the previous inquiry which has already completed,
> and the target responds with "task not in task set", which
> is understandable since the command has already completed.
> I used the latest .169 code.

its too old anyways. try subversion's repository. but I doubt it will
help in your case.

> I don't see this problem with the latest linux-iscsi.sfnet
> code and have interoperated with many other initiators,
> so I'm fairly confident there's a bug in open-iscsi somewhere.

i'm pretty sure it is a bug in open-iscsi. which target are you using?
can we get remote access?

> 
> > Prior to starting from-scratch the data path code we did evaluate the 
> > sfnet
> > Initiator. And eventually decided against patching it. Instead, we reused
> > its Discovery, Login, etc. control plane code.
> > Technically, it was the shortest way to achieve the (1) and (2) goals 
> > stated
> > above. We believe that it remains the easiest and the most practical 
> > thing
> > on the larger scale of: iSCSI for Linux.
> >
> >
> > STATUS
> > ======
> >
> > There's a 100% working code that interoperates with all (count=5) iSCSI
> > targets we could get our hands on.
> >
> > The software was tested on AMD Opteron (TM) and Intel Xeon (TM).
> >
> > Code is available online via either Subversion source control database or
> > the latest development release (i.e., the tarball containing Open-iSCSI
> > sources, including user space, that will build and run on kernels 
> > starting
> > 2.6.10).
> >
> >         http://www.open-iscsi.org
> >  
> > Features:
> >
> >     - highly optimized and small-footprint data path;
> >     - multiple outstanding R2Ts;
> >     - thread-less receive;
> >     - sendpage() based transmit;
> >     - zero-copy header processing on receive;
> >     - no data path memory allocations at runtime;
> >     - persistent configuration database;
> >     - SendTargets discovery;
> >     - CHAP;
> >     - DataSequenceInOrder=No;
> >     - PDU header Digest;
> >     - multiple sessions;
> >     - MC/S (note: disabled in the patch);
> >     - SCSI-level recovery via Abort Task and session re-open.
> >
> >
> > TODO
> > ====
> >
> > The near term plan is: test, test, and test. We need to stabilize the
> > existing code, after 5 months of development this seems to be the right
> > thing to do.
> >
> > Other short-term plans include:
> >
> > a) process community feedback, implement comments and apply patches;
> > b) cleanup user side of the iSCSI open interface; use API calls 
> > (instead of
> > directly constructing events);
> > c) eliminate runtime control path memory allocations (for Nop-In, 
> > Nop-Out,
> > etc.);
> > d) implement Write path optimizations (delayed because of the 
> > self-imposed
> > submission deadline);
> > e) oProfile the data path, use the reports for further optimization;
> > f) complete the readme.
> >
> > Comments, code reviews, patches - are greatly appreciated!
> >
> >
> > THANKS
> > ======
> >
> > Special thanks to our first reviewers: Christoph Hellwig and Mike 
> > Christie.
> >
> > Special thanks to Ming Zhang for help in testing and for insightful
> > questions.
> >
> >
> > Regards,
> >
> > Alex Aizman & Dmitry Yusupov
> >
> > =============================================
> >
> > The following 6 patches alltogether represent the Open-iSCSI Initiator:
> >
> > Patch 1:
> >   SCSI LLDD consists of 3 files:
> >   - iscsi_if.c (iSCSI open interface over netlink);
> >   - iscsi_tcp.[ch] (iSCSI transport over TCP/IP).
> >
> > Patch 2:
> >   Common header files:
> >   - iscsi_if.h (iSCSI open interface over netlink);
> >   - iscsi_proto.h (RFC3720 #defines and types);
> >   - iscsi_ifev.h (user/kernel events).
> >
> > Patch 3:
> >   drivers/scsi/Kconfig changes.
> >
> > Patch 4:
> >   drivers/scsi/Makefile changes.
> >
> > Patch 5:
> >   include/linux/netlink.h changes (added new protocol NETLINK_ISCSI)
> >
> > Patch 6:
> >   Documentation/scsi/iscsi.txt
> >


  reply	other threads:[~2005-03-12 17:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4229e34e.7e535078.5bc3.0b5eSMTPIN_ADDED@mx.googlegroups.com>
2005-03-06  1:02 ` [ANNOUNCE 0/6] Open-iSCSI High-Performance Initiator for Linux Mike Christie
2005-03-12 16:55 ` Dave Wysochanski
2005-03-12 17:08   ` Dmitry Yusupov [this message]
2005-03-07  7:03 Alex Aizman
2005-03-09  5:04 ` Matt Mackall
2005-03-09  5:51   ` Alex Aizman
2005-03-09  6:05     ` Matt Mackall
2005-03-09  6:25       ` Alex Aizman
2005-03-09 19:29         ` Bryan Henderson
2005-03-09 19:41           ` Matt Mackall
2005-03-10  2:09           ` Alex Aizman
2005-03-09 22:21         ` Lars Marowsky-Bree
2005-03-10  2:36           ` Alex Aizman
2005-03-10 10:27             ` Lars Marowsky-Bree
2005-03-11  7:00               ` Dmitry Yusupov
2005-03-09  6:25       ` Dmitry Yusupov
2005-03-09  6:50         ` Matt Mackall
2005-03-09  7:18           ` Dmitry Yusupov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1110647289.16456.6.camel@mylaptop \
    --to=dmitry_yus@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=open-iscsi@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox