[openib-general] ISER cleanup

[Dan Bar Dov]

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch at lst.de] 
> 
> Note that we care very little about specifications for in-kernel APIs.
> so the distinction between a standard API and extension make 
> little sense, in the end we'll probably only have more or 
> less non-standard APIs.
OK, the extended API deals with the connection establishement. 
If we'll be using the "socket" semantics the extended API will be the socket.
If its something else, then whatever it is. We still don't have any sensible solution to that 
since it is not possible to start the QP in user space and then use it in kernel. 
In any case, we can combine the two APIs.
> 
> > > iser_types.h
> > > 	delete typdef void * iser_api_handle_t.
> > > 	replace usage of iser_api_handle_t with "void *".
> > > 	Ditto for all "void *" typedefs in that file.
> > OK
> > 
> > > 
> > > 	Kernel already defines scatter-gather lists type.
> > The iser_data_buf struct can point to a scatterlist array 
> but can also be used to point at a single buffer. 
> > It does not replicate scatterlist but allows us to deal 
> with two types of registrations - single buffer and scatter lists.
> 
> We're planning to get rid of non-S/G list data transfer in 
> the scsi subsystem for 2.6.14+.  See the tree at 

This is fine for the data, however, we also need to register PDU memory 
which is not in sg lists. This is most visible with unsolicited data, where part 
or all of the data is sent along with the PDU in a single send-control. We considered 
packing the PDU in a single element sg list, but it seems ridiculous.

> 
>   
> http://www.kernel.org/git/gitweb.cgi?p=linux/kernel/git/jejb/s
> csi-block-2.6.git;a=summary

> in there everything but the sg,st and osst drivers doesn't submit non-S/G requests anymore, and these last drivers is beeing worked on already.

>> We are going to simplify the local memory registrations by registering all memory like in the SRP driver.
>> We do not understand some of the substance issues - for example, dma 
>> related comments - are taken care of by iscsi, not the transport. The io_mmu comment, we completely do not understand - there was some platform specific code, but its all gone now.

> Basically all use of virt_to_{phys,bus} / {phys,bus}_to_virt is wrong.
> You must use proper dma mapping routines.  See Documentation/DMA-API.txt in the kernel tree for details.

NP.