On Tue, 14 Dec 2004 09:29:19 +0200, Danny Braniss <[EMAIL PROTECTED]> 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
