[stgt] towards new iser implementation

[Alexander Nezhinsky]

Hi

It's been quite a while since i promised some patches for iser. Meanwhile,
i was experimenting with the code trying different ideas and implementation
patterns.

Finally, i've ended up with an implementation of iser, which diverges quite
radically from the original one. It looks promising, introducing some
performance improvements and paving a way for some more. On the practical
side, it seems to do away with the occasional data corruption, reported
during the last year by several users - at least their test scenarios now
pass ok.

I would like to contribute it and to reach a new, better and stable
implementation of iser. I'm not sendng any code now because producing an
acceptable patch instantly is quite problematic. The fact is that the new
code does not quite follow the current tgt's iscsi framework. There are
few reasons for that, all related to how my changes have evolved.

My first step was to escape from the iscsi "sub-transport" API, because it
does not fit iser flow and requires bunches of error-prone "glue" code.
Mainly i wanted to decouple iser rx/tx flow from using EPOLLIN/EPOLLOUT 
events (that's why I don't know how to fix the original bug mentioned 
above, as i suspect it was related to that flow, which became irrelevant).

Then i realized that the "state machine" required by iser is so slim that
it can be much easier to implement it separately.

The next objective was to avoid memory copies, so that i stopped using 
req/rsp buffers present within iscsi connection struct. There were some
other changes so i introduced a separate iser task structure, and a common
iscsi connection header (both tcp and iser extend it).

I hoped to be able to make common use of text processing functions etc.,
but it proved impossible because they expected the iscsi task buffer. Thus
i had to replicate most of the functions because of these purely technical
reasons.

To accommodate with the gap between iscsi/tcp and iser it was simpler to 
implement iser in a separate lld (called "iser"). This does not have to
remain this way and can be reversed if the obstacles described above are
solved. In particular a new iscsi transport api should be devised. If it 
is too difficult, we may consider leaving iser lld separate.

To proceed in a comprehensive and controlled manner, we need to make a
series of changes in iscsi code infrastructure. We just have to agree 
on the proper way of doing it.

I propose starting with the "rectification" of iscsi text functions, by
changing them to accept plain char * buffers, making them independent from
iscsi structures specifics. Such semantic changes do not alter the logic
of the existing code. For this I can send some patches shortly.

Meanwhile, we can start discussing design goals/details, so that i could
start shaping the subsequent patches from what i have, according to the 
decisions and to fit the existing framework. 

What do you think?

Alexander Nezhinsky
--
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