| |||||||||||||
Virtualization and InfiniBandVirtualization and InfiniBandPosted Aug 7, 2009 18:04 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: Virtualization and InfiniBand by abacus Parent article: AlacrityVM
This is because the IB stack has been designed for high throughput and low latency. As opposed to what? Doesn't every protocol seek to be fast? Does IB make different tradeoffs than the alternatives?
(Log in to post comments)
Virtualization and InfiniBand Posted Aug 7, 2009 18:37 UTC (Fri) by abacus (subscriber, #49001) [Link] > > This is because the IB stack has been designed for high throughput and low latency.> As opposed to what? Doesn't every protocol seek to be fast? Does IB make different tradeoffs than the alternatives? IB is a technology that comes from the supercomputing world and that has a higher throughput and a lower latency than any other popular storage or networking technology (IDE, SATA, 10 GbE, ...). Key features of IB are support for zero-copy I/O (RDMA) and the possibility of performing I/O without having to invoke any system call, even for user-space processes. Some impressive graphs can be found in this paper: Performance Analysis and Evaluation of Mellanox ConnectX InfiniBand Architecture with Multi-Core Platforms. Note: I'm not affiliated with any vendor of IB equipment.
Virtualization and InfiniBand Posted Aug 7, 2009 20:31 UTC (Fri) by giraffedata (subscriber, #1954) [Link] has a higher throughput and a lower latency than any other popular storage or networking technology (IDE [ATA], SATA, 10 GbE, ...) Nonetheless, ATA, SATA, and 10 GbE were all designed to have high throughput and low latency. So one can't say that being designed for high throughput and low latency sets IB apart from them. So what does? Were the IB engineers just smarter? Did they design for higher cost of implementation? Did they design for implementation technology that wasn't available when the alternatives were designed?
Virtualization and InfiniBand Posted Aug 7, 2009 21:05 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
IB is faster and lower latency, but is significantly more expensive, has shorter cable length restrictions, (IIRC) many more wires in the cables (which make them more expensive and more fragile)
IB was designed for a system interconnect within a rack (or a couple of nearby racks)
ATA and SATA aren't general interconnects, they are drive interfaces
10 GbE is a fair comparison for IB, but it was designed to allow longer cable runs, with fewer wires in the cable (being fairly compatible with existing cat5 type cabling)
Virtualization and InfiniBand Posted Aug 8, 2009 7:24 UTC (Sat) by abacus (subscriber, #49001) [Link]
What you wrote above about cabling is correct but completely irrelevant in this discussion. What I proposed is to use the IB API's (RDMA) and software stack (IPoIB, SDP, iSER, SRP, ...) for communication between a virtual machine and the host system. In such a setup no physical cables are necessary. An additional kernel driver will be necessary in the virtual machine however that implements the RDMA API and allows communication between guest and host.
Virtualization and InfiniBand Posted Aug 8, 2009 9:27 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
if you are talking a virtual interface, why would you use either?
define a driver that does page allocation tricks to move data between the client and the host for zero-copy communication. at that point you beat anything that's designed for a real network.
then you can pick what driver to run on top of this interface, SCSI, IP, custom depending on what you are trying to talk to on the other side.
Virtualization and InfiniBand Posted Aug 8, 2009 10:52 UTC (Sat) by abacus (subscriber, #49001) [Link] As I wrote above, implementing an IB driver would allow to reuse a whole software stack (called OFED) and the implementation of several communication protocols. Yes it is possible to develop all this from scratch, but that is more or less like reinventing the wheel.
Virtualization and InfiniBand Posted Aug 13, 2009 4:54 UTC (Thu) by jgg (guest, #55211) [Link]
10GBASE-T is not compatible with Cat5e, it needs Cat6 cabling. It is also still a pipe dream, who knows what process node will be necessary to get acceptable cost+power. All 10GIGE stuff currently is deployed with CX-4 (Identical to SDR IB) or XFP/SFP+ (still surprisingly expensive).
The big 10GIGE vendors are desperately pushing the insane FCoE stuff to try and get everyone to re-buy all their FC switches and HBAs since 10GIGe has otherwise been a flop. IB is 4x as fast, and 1/4th the cost of 10GIGE stuff from CISCO :|
Virtualization and InfiniBand Posted Aug 8, 2009 7:42 UTC (Sat) by abacus (subscriber, #49001) [Link] Yes, 10 GbE has been designed for low latency. But look at the numbers: the best performing 10 GbE interface today (Chelsio) has a latency of 3.8 us [1] while recent IB interfaces have a latency of 1.8 us [2]. The difference is small but it matters when communicating messages that are less than 64 KB in size. And IB interfaces do not cost more than 10 GbE interfaces that support iWARP.IB interfaces have a lower latency than 10 GbE interfaces because the whole IB stack has been designed for low latency while 10 GbE had to remain compatible with Ethernet. References:
Virtualization and InfiniBand Posted Aug 8, 2009 9:24 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
yes, IB has lower latencies than 10GB ethernet
10G ethernet isn't low latencies at all costs. it benifits/suffers from backwards compatibility issues.
it also allows for longer cable runs than IB
it's not that one is alwaysbetter than the other, it's that each has it's use
if you are wiring a cluster of computers and price is not an issue, then IB clearly wins
if you are wiring a building, than IB _can't_ do the job, but 10G Ethernet can, so it clearly wins
Virtualization and InfiniBand Posted Aug 8, 2009 11:00 UTC (Sat) by abacus (subscriber, #49001) [Link] As I wrote above, the physical limitations of IB are not relevant in the context of the AlacrityVM project. These limitations only apply to the physical layer of the IB protocol and not to the higher communication layers. By the way, the InfiniBand Architecture Specification is available online. And
Virtualization and InfiniBand Posted Aug 29, 2009 12:18 UTC (Sat) by abacus (subscriber, #49001) [Link] Note: there are already kernel drivers in the Linux kernel that use this concept for communication between a virtual machine and the hypervisor or another virtual machine. These drivers are ibmvscsi (initiator, runs in the virtual machine) and ibmvstgt (target, runs in the entity exporting the SCSI device). See also Virtual SCSI adapters for more information.
Virtualization and InfiniBand Posted Aug 29, 2009 17:13 UTC (Sat) by giraffedata (subscriber, #1954) [Link] You've given an example I actually know something about, so I can comment further. You're talking about the mechanism used on IBM's System P processors (which come standard with virtual machines) to allow a server in virtual machine S to present a SCSI disk device to client virtual machine C. The server in S bases its disk devices on real SCSI disk devices (e.g. it splits a 10G real SCSI disk into 5 2G disks, one for each of 5 client virtual machines), and the actual data transfer is conventional DMA done by the real SCSI HBA to the memory of C, using hypervisor facilities specifically designed for this I/O server VM application. AFAICS the only infiniband-related part of this is SRP (SCSI RDMA (Remote DMA) Protocol). SRP is how the program running in S initiates (by communicating with C) that DMA into memory C owns, much as a server at the end of an IB cable might set up to transmit data down the IB wire into the client's memory. And as I recall, SRP is simple and not especially fast or low-latency -- just what anybody would design if he needed to communicate DMA parameters. A person could be forgiven for just reinventing SRP for a particular application instead of learning SRP and reusing SRP code.
Virtualization and InfiniBand Posted Sep 2, 2009 8:02 UTC (Wed) by xoddam (subscriber, #2322) [Link]
Wish *I* got a System P processor standard with *my* virtual machine!
|
|||||||||||||