My project wish-list for the next 12 months

[Scott M. Ferris]

On Tue, 14 Dec 2004 09:29:19 +0200, Danny Braniss <danny at cs.huji.ac.il> wrote:
> Great!, we seem to be on the same wavelength, im now writing (at about one
> char a minute) the login user program, and somehow - to be discovered -, the
> socket will be passed to the kernel.
> my main efford, at the moment, is a) to &^%$$## understand the RFC (i think
> they used a scrambler) and b) define the data structures.

How do you plan on handling cases where the user program blocks and
can't login again (because of a page fault for code or data,
allocating a new socket in the kernel, allocating a new socket buffer
in the kernel, etc)?

One of the major problems any software-only iSCSI initiator has is
dealing with memory deadlocks.  The OS may try to write out one or
more pages in order to free up memory.  If the iSCSI initiator needs
to allocate memory (directly or indirectly in the TCP stack) in order
to complete that write, you've got a circular dependency where in
order to get free memory you need to have free memory.  
Hardware-based iSCSI HBAs solve this by having their own memory and
TCP stack separate from the OS.  Software-only iSCSI initiators such
as linux-iscsi usually just hope it doesn't happen, and that's why I
don't usually recommend software-only iSCSI initiators to anyone.

Having a user program login is fine for SendTargets discovery and
testing, but if you're planning on getting a reliable iSCSI initiator,
you'll probably need to do the login from within the kernel, and make
sure you have all of the resources needed to do that reserved (wire
pages into RAM, etc).  The hard part of that is making sure you have
all the resources needed to send and receive TCP packets reserved, as
well as the resources to establish new connections in case the
existing connections is closed or aborted.  The linux-iscsi initiator
doesn't even attempt this, and just hopes deadlocks don't happen very
often.

I used to be the main (and for most of that time, only) developer for
the linux-iscsi initiator.  When I first took over the initiator, it
used the approach of doing iSCSI session login from a daemon, and
passing the socket down into a kernel module.  I had to take that out
because it deadlocked too easily.  I wouldn't recommend that approach.

-- 
Scott M. Ferris