User guide

36 Implementing Cisco InfiniBand on IBM BladeCenter
enqueue the requested work, and return immediately with the request not completed (often,
not even started) and the data buffers still in use.
The use of asynchronous sockets is standard under the Windows® operating systems.
Sockets-based communications for Windows programs is always asynchronous, and
therefore requires no modification to operate over SDP. Historically, UNIX® and Linux®
applications have used synchronous sockets and, therefore, do not map transparently into
the SDP protocol. To accommodate this mismatch, a synchronous-to-asynchronous
conversion process can be provided between the sockets interface to the application
(synchronous) and the SDP interface (asynchronous). This conversion can involve delaying
the return from the call, copying data buffers, or other methods that trade some performance
and efficiency to achieve full compatibility with existing applications.
In addition, synchronous sockets are being developed and exploited in UNIX and Linux
environments today. As they become more standard, software will exploit this interface and
will map more easily onto higher-efficiency transports through the use of SDP or similar
protocols. With many applications already being cross-compiled onto alternate operating
systems and platforms, it is very possible that compile options might already exist to use
asynchronous sockets.
3.2.3 Storage RDMA Protocol
Storage RDMA Protocol (SRP) is the industry standard storage protocol for InfiniBand. SRP
provides a standard SCSI protocol transport over InfiniBand. The SCSI communications
generated by either an application or the file system (often part of the operating system), are
issued directly to the SRP interface, which provides full legacy support. The SCSI protocol
and the data structures used in SCSI are transported without modification by SRP over
InfiniBand, just as SCSI is transported over Fibre Channel (FCP protocol), and over TCP/IP
(iSCSI protocol).
The areas in which FC, iSCSI, and SRP differ are related to the network aware functions,
such as device discovery and enumeration, multi-path support, and path failover. There are
two technical solutions for mapping the network aspects on top of SRP: emulation of Fibre
Channel and its network and naming constructs; or emulation of iSCSI and its network and
naming constructs.
The current InfiniBand storage implementations, specifically the Topspin InfiniBand-Fibre
Channel bridges, implement Fibre Channel emulation. This provides the most seamless
interoperability between existing Fibre Channel SANs and new InfiniBand-connected host
systems. The host applications see a normal SCSI connection and through the Topspin
drivers can treat the connection as they would a normal Fibre Channel connection. Storage
vendor specific load balancing and failover drivers operate over SRP and mixed SRP-FCP
SANs without any awareness of it communicating over different fabrics.
When the mixed SAN environment gets more complicated, and both hosts and storage are
spread on both the InfiniBand and non-InfiniBand (Fibre Channel or iSCSI) fabrics, bridging
them all together in a Fibre Channel emulation mode will become more difficult.
Voltaire has been leading an effort, with the support of IBM and others, to standardize around
a more iSCSI-like view of the network. When iSCSI was developed, a very rich set of
functions was architected to provide a well-defined and interoperable mechanism for
discovery, naming, authorization, and most of the fabric-aware functions. By utilizing iSCSI
and its services such as iSCSI names services (iSNS), SRP picks up a standard method of
naming so that devices on the InfiniBand fabric can recognize devices on Fibre Channel or
iSCSI fabrics through a common namespace that understands how to map names from fabric
to fabric. Several such functions are enabled or made simpler through the use of an