[stgt] [PATCH RFC] new iser code

[Alexander Nezhinsky]

Pete Wyckoff wrote:
> 
> Why did you duplicate so many shared iscsi functions?
> iser_scsi_cmd_done etc. should not know about the particulars of the
> transport.  You got rid of the whole transport abstraction?

There are few reasons. First, my initial motivation was to escape 
the api of iscsi sub-transports, because it did not suit well for iser. 
Then, the login and text code was not generic and became unusable
outside the above-mentioned api.
So i circumvented iscsi transport abstraction for iser, and duplicated
some other code, but if we formulate a new transport api 
suitable for both iscsi/tcp and iser then it can be brought back.
Actually this is one possibility for a new design, and i'd be happy 
to discuss it.

Perhaps you missed my explanations, posted previously on the list:
http://lists.wpkg.org/pipermail/stgt/2010-June/003842.html

>> This code seems to fix an occasional data corruption that happens
>> with the current version.
> 
> This would be interesting.  How about isolating the changes, and
> describing them one at a time?

If you mean the changes that fix the data corruption, then i can't 
isolate them. A large portion of the code was rewritten and then the bug
just did not seem to be there. I suspect it was related to the handling of
POLLIN/POLLOUT events, and getting rid of them was roughly the first things
that i strove to do.

>> The code implies RDMA-only mode of work. This means the first burst
>> incl. immediate data should be disabled, so that the entire data transfer
>> is performed using RDMA. It introduces some preparations for handling
>> other (general) scenarios, but as tgt has no framework for multi-buffer
>> commands, these extra code segments are either commented or conditioned
>> upon events that should never take place. All such places have a ToDo
>> comment over them.
> 
> Immediate data is a nice optimization for short writes.  I'd like to
> support it if possible.

Sure, i'm all in for it. But if we are going to get rid of mem.copies, then
the ability to submit scatter-gather lists as cmd data is necessary.
As I mentioned, in the new iser code, most of the preparations are in place.
It only lacks the "last-step", the actual translation of the buffer list 
into the SG vector, yet to be defined.

> I'm excited that you're starting to work on this, and contributing
> it back.  But it's hard to evaluate what you're doing in a big patch
> like this.

I've been thinking how to submit this work for quite a long time, 
given its "non-incremental" nature. Then I decided just to start somehow.
I've suggested to begin with the text functions first, and discuss 
the iscsi/iser "core" in the background.
I sent this big "as is" patch upon Tomo's request - it was intended as 
an illustration and RFC only.

Anyway, I will be happy to answer your specific questions about the code.

Alexander


--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html