In this paper, we evaluate the performance of a software iSCSI initiator over a software iWARP stack. Through measurements and simulations, we quantify the protocol processing costs of the iSER, Verbs, and iSCSI control layers in the fast path. We project the stack performance at a micro-benchmark level, by combining these costs with the protocol processing costs associated with a software iWARP stack developed at Intel. Our implementation is based on the Datamover architecture. This allows us to compare the performance of the stack with an alternative iSCSI solution that we implemented on a TCP/IP transport stack. We present quantitative data comparing the two stacks by evaluating them with respect to different processing components like control processing, data placement, copy, and CRC. Our data shows that for software-only initiators, both stacks achieve equivalent performance for common iSCSI I/O sizes. Our results demonstrate that software iSCSI over iWARP on a general-purpose CPU does not carry a significant performance penalty over traditional software iSCSI Therefore, future iSCSI-based storage over IP networks can benefit from the efficiency of RNIC-based storage targets while deploying a software iWARP stack for client storage initiators

The iSCSI protocol is a key building block for enabling IP-based network storage. High performance iSCSI implementations that can support multi-gigabit storage traffic throughput at low latencies are important in facilitating the widespread deployment of this technology. Motivated by this, our work presented in this paper focuses on analyzing the underlying architectural characteristics of iSCSI packet processing and quantifying its compute/memory requirements. Our analysis and characterization methodology is based on in-depth measurement experiments of iSCSI packet processing performance on Intel/sup /spl reg// Xeon/spl trade/ processor, running the Red Hat Linux operating system. Our measurement data shows the achievable throughput and consumed CPU utilization at different disk I/O sizes. We also study the overhead of integrity checks on iSCSI performance by enabling CRC computation. To understand the source of the iSCSI processing costs, we then do a detailed analysis of the architectural characteristics in terms of path length, cycles spent per instruction, cache misses at all levels and branch mispredictions.