Date: Tue, 14 Dec 2004 21:49:54 +0100 From: Wilko Bulte <wb@freebie.xs4all.nl> To: "Scott M. Ferris" <sferris@gmail.com> Cc: Peter Blok <pblok@bsd4all.org> Subject: Re: My project wish-list for the next 12 months Message-ID: <20041214204954.GC1356@freebie.xs4all.nl> In-Reply-To: <1eea89cd041214114766fd34dc@mail.gmail.com> References: <20041214072922.2604543D1D@mx1.FreeBSD.org> <1eea89cd041214114766fd34dc@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 14, 2004 at 01:47:15PM -0600, Scott M. Ferris wrote.. > On Tue, 14 Dec 2004 09:29:19 +0200, Danny Braniss <danny@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 Downside: TOE cards are not cheap though.. -- Wilko Bulte wilko@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041214204954.GC1356>