On Mon, 24 Jan 2011 21:37:21 +0200 Alexander Nezhinsky <alexandern@xxxxxxxxxxxx> wrote: > These patches contain a re-write of the iser code. Re-sending after > fixing NOP and bi-dir commands issues. > > A separate transport lld (named "iser") is defined. > > New header iser.h is created. > File iscsi_rdma.c is replaced by iser.c > > File iser_text.c contains the iscsi-text processing code replicated > from iscsid.c. This is done because the functions there are > not general enough, and rely on specifics of iscsi/tcp structs. > This file will hopefully be removed after the code unification. > > Additional portions of code are copied from iscsid.c and changed > appropriately. These changes do not always represent code duplication, > but rather simplify or optimize the flow for iSER. > > This code fixes an occasional data corruption that happens > with the current version. > > There are some unhandled error cases and rare conditions, left > until there is a solid common iscsi framework to rely upon. Most of > them are marked with ToDo comments. > > The code is fairly RDMA-transport agnostic (ib/iwarp). > > The code implies RDMA-only mode of work. This means the "first burst" > including immediate data should be disabled, so that the entire > data transfer is performed using RDMA. > This is achieved by setting: > target->session_param[ISCSI_PARAM_INITIAL_R2T_EN].val = 1; > target->session_param[ISCSI_PARAM_IMM_DATA_EN].val = 0; > in iser_target_create(). > > This mode is perhaps the most suitable one for iser in the majority > of work scenarios. The only concern (performanc-wise) may arise about > relatively small WRITE ios, which enjoy theoretically lower latencies > using IB SEND instead of RDMA-RD. > > Implementing such "Immediate Data" mode (and any other mode that > implies non-empty FirstBurst) is meanwhile precluded because it would > lead to multiple buffers per iSER task (e.g. ImmediateData buffer > received with the command PDU, and the rest of the data retrieved > using RDMA-RD). > > The code introduces some preparations for handling such general scenarios, > but as tgt has no framework for multi-buffer commands, > these extra code segments are either commented out or conditioned upon > events that should never take place. All such places have a ToDo > comment over them. > > Apart of the known issues, there are feature regressions to be addressed > in the next patches. Most notably AHS and bi-dir handling. So now it supports AHS and bidi. This is ready for the merge? If so, please update doc/README.iser too. Thanks, -- 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
