On Thu, 24 Jun 2010 21:34:52 +0300 Alexander Nezhinsky <alexandern@xxxxxxxxxxxx> wrote: > 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. Sounds great! Thanks for working on the iser code. > 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). You mean that you send page cache to initiators (like sendpage in the case of tcp)? Your changes work nicely too for tcp? > 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. With a separate iser lld, if a tcp-only initiator tries to connect to a iser target, what happens? tcp and iser can't share iSCSI listen port (3260), so we can't run tcp and iser targets at the same time? > 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. Yeah. > 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. Sounds reasonable but as I wrote above, iser and tcp could have the common buffer management. Please send all the patches that you have now (no need to clean up them). I just want to see the whole picture first. Btw, your new implementation uses the single thread model? Or as I did for tcp, it uses pthread per target? -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
