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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
