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 |