-*- mode:text; tab-width:8; fill-column:72; -*-
vi: set tabstop=8 textwidth=72:
------------------------------------------------------------------------

	This file contains a list of TODO items for UNH-iSCSI.	There is
	no strong order to this list, just put things in here as they
	come up.  Please try to keep this up to date as items are
	completed -- eaburns


Fri May 16 13:47:39 EDT 2008 -- eaburns
        iSER and task management commands.  According to a comment
        somewhere in the code TM commands are not handled in iSER
        yet...  This is a *big* pain in kernel-space.
	--- update ---
	It turns out that this comment is in initiator_tx.c when
	transmitting task management commands.  The deal is that we *do*
	transmit the command, however, we do not inform iSER of the task
	termination.  So, I believe that we have a task state leak in
	the iSER code (since iSCSI never tells iSER to release the state
	for the task).


Fri May 16 13:46:41 EDT 2008 -- eaburns
        Better shutdown handling in kernel-space with iSER.  This seems
        to work a bit better than it was working previously (the modules
        can now be unloaded), however, reconnecting and re-loading the
        modules seems to be a bit fuzzy.


Fri May  2 07:53:53 EDT 2008 -- eaburns
        Cleanup the Makefile.  This is full of variables that are used
        for configuration.  These should be documented and shuffled
        around where possible so that the user doesn't need to look
        around very far in the Makefile to find the variables that they
        need to change.


Fri May	 2 07:24:47 EDT 2008 -- eaburns
	This would be a rather large change:
	Eventually a datamover arch (DA) implementation should be made
	that uses the traditional iSCSI PDUs in order to transfer data
	between the nodes.  The advantage of this is that there would no
	longer be a need for two control paths in the target and
	initiator code (the iSER and traditional code paths are
	currently separate in a lot of places).	 Additionally, this
	would remove the requirements for all of the RDMA_MODE
	pre-processor conditionals.  Instead of using pre-processor
	conditionals for iSER mode, a different set of DA verbs could be
	registered.  This would make the code much cleaner, and it would
	get rid of this crazy requirement that RDMA_MODE is either
	enabled or disabled at compile time.


Tue Apr 29 08:39:51 EDT 2008 -- eaburns
	Look into the proper way to flow-control IRD/ORD.  It has been
	suggested that there is a way (using OFA) to set the IRD/ORD
	values on the RNICs.  This would possibly give better
	performance than how it is handled right now (the target blocks
	until a ReadRequest is available).


Thu Mar 27 09:24:04 EDT 2008 -- eaburns
	Look at the MaxOutstandingUnexpectedPDUs negotiation to
	determine how many RDMA Recv buffers to allocate.  Technically
	Enable_Datamover, or some other iSER verb should be called
	*just* *before* FFP, in this verb we should post all of the
	iSCSI command receive buffers.

	Currently, we guess the number of MaxOutstandingPDUs (by a
	define in iser.h) and allocate them all at the beginning of
	the hello message exchange.  This is incorrect, instead we
	should allocate a sufficient number of buffers to perform
	iSCSI login (maybe just have two available at all times?) and
	after login is complete, but *before* moving to FFP we should
	allocate MaxOutstandingUnexpectedPDUs number of recv buffers
	all large enough to hold an iSER/iSCSI header and
	{Target,Initiator}MaxRecvDataSegmentLength number of bytes
	(for unsolicited data).

	Buffers allocated from the (possibly) pre-registered caches
	should *always* be the same size (using the Max Recv DSL stuff
	mentioned above and the size of the iSER/iSCSI headers).  This
	will get rid of a bunch of logic when creating a
	pre-registered pool of buffers (see TODO item from Fri Mar 21
	13:31:26 EDT 2008).


Tue Jul 10 14:43:30 EDT 2007 -- eaburns
	Use the IRRELEVANT_WITH_RDMA flag when performing
	negotiations.  Currently, I believe, this flag is ignored and
	Irrelevant keys are negotiated normally when
	RDMAExtensison=Yes.  This may already be used, however, my
	testing seems to show that it doesn't work correctly.
