[openib-general] [PATCH 3/6] [RFC] iser initiator

[Mike Christie]

Or Gerlitz wrote:
> Christoph Hellwig wrote:
> 
> 
>>>+static int iser_dma_map_task_data(struct iscsi_iser_cmd_task *p_iser_task,
>>>+				  struct iser_data_buf       *p_data,
> 
> ...
> 
>>>+	if (p_data->type == ISER_BUF_TYPE_SINGLE) {
>>>+		p_iser_task->data_len[iser_dir] = p_data->size;
>>>+		dma_addr = dma_map_single(dma_device,p_data->p_buf, p_data->size,
> 
> 
>>I'd say kill the non-SG case.  We're in the progress of removing non-SG
>>commands in the scsi midlayer, and I'm pretty sure they won't exist
>>anymore before the iser code merged.
> 
> 
> Indeed i see that driver/scsi/iscsi_tcp.c of 2.6.16-rc1 (and on) does 
> not support non-SG SCSI commands.

We should still support them in 2.6.16. We have not cleaned out that 
code yet. We are doing the header fixup at the same time. That patch to 
use change when we use sendmsg/sendpage should not have broken the 
non-sg case. Did it?

  Can you confirm that as of 2.6.16 a
> SCSI LLD does not need to support the non-SG case?

For new software iscsi I do not think there is no need to support non-sg 
commands. There is only one depreciated ioctl that we could ever get a 
non-sg command (I do not think someone is using iscsi and osst) and that 
can be converted pretty easily. I had sent a patch long ago but it did 
not get merged and I did not much care about it since someone should not 
be using it and newer iscsi code.


> 
> OK - the code for upstream will assume only SG commands.
> 
> Now, regardless of when iSER is to be merged, it is used with 2.6.15 and 
> older kernels that do issue non-SG commands. I wonder what would be the 
> simplest patch to support it, does it make sense to use virt_to_page on 
>   sc->request_buffer to compose one entry SG on the fly and use it down 
> the code?
> 

For upstream code we are going to want something that is clean. By the 
time iscsi_iser goes in testing for "if (!sc->use_sg)" will be one of 
those things reviewers ask you to remove becuase it cannot happen in the 
upstream kernel.

Plus there seems like there is some duplication between the iscsi_tcp 
and iscsi_iser modules for this type of operation. That is just going by 
when I last looked at your code. I did not see anything posted on 
open-iscsi or linux-scsi yet so I do not know what this patchset looks 
like. But it has been stated before that we might have to break up some 
of the core iscsi code to be shared with iscsi_iser and iscsi_tcp. 
Managing mempools of iscsi tasks and translating scsi_cmnd scatterlists 
to iscsi specifics seems like a candidate. I did not see your current 
code though so I am not 100% sure.