… which is of course massive overkill. But fun. It should increase the raw bandwidth available between the two machines from 1Gbps to 20Gbps (with one link) and 40Gbps with both links bonded. It was a bit of a surprise to me when I looked around at prices of second-hand kit to realise that InfiniBand was so much cheaper to acquire than Fibre Channel; the kit I acquired cost less than £100 all in whereas FC kit would be in the region of £1,000, and InfiniBand is generally quicker. There is of course 16Gb FC and 10Gb InfiniBand, but that is hardly comparing like with like. So what is this overkill for? Networking of course. I’ve acquired two HP InfiniBand dual link cards which means I can connect my workstation to my server :- 
Using dual links is of course overkill on top of overkill, but given that these cards have dual links, why not use them? And it does give a couple of experiments to try later. To prepare in advance, the following network addresses will be used :-
| Server | Link Number | IPv4 Address | IPv6 Address |
|---|---|---|---|
| A | 1 | 10.255.0.1 | AAISP:d00d::1 |
| A | 2 | 10.255.1.1 | AAISP:d00f::1 |
| B | 1 | 10.255.0.254 | AAISP:d00d:2 |
| B | 1 | 10.255.1.254 | AAISP:d00f:2 |
Yes I have cheated for the IPv6 addresses! The first step is to configure each “server” … one is running Debian Linux, and the other is running FreeBSD.
Configuring Linux
This was subject to much delay whilst I believed that I had a problem with the InfiniBand card, but putting the card into a new desktop machine caused it to spring back to life. Either some sort of incompatibility with my old desktop (which was quite old), or some sort of problem with the BIOS settings.
Inserting the card should load the core module (mlx4_core) automatically, and spit out messages similar to the following :-
[ 3.678189] mlx4_core 0000:07:00.0: irq 108 for MSI/MSI-X [ 3.678195] mlx4_core 0000:07:00.0: irq 109 for MSI/MSI-X [ 3.678199] mlx4_core 0000:07:00.0: irq 110 for MSI/MSI-X [ 3.678204] mlx4_core 0000:07:00.0: irq 111 for MSI/MSI-X [ 3.678208] mlx4_core 0000:07:00.0: irq 112 for MSI/MSI-X [ 3.678212] mlx4_core 0000:07:00.0: irq 113 for MSI/MSI-X [ 3.678216] mlx4_core 0000:07:00.0: irq 114 for MSI/MSI-X [ 3.678220] mlx4_core 0000:07:00.0: irq 115 for MSI/MSI-X [ 3.678223] mlx4_core 0000:07:00.0: irq 116 for MSI/MSI-X [ 3.678228] mlx4_core 0000:07:00.0: irq 117 for MSI/MSI-X [ 3.678232] mlx4_core 0000:07:00.0: irq 118 for MSI/MSI-X [ 3.678236] mlx4_core 0000:07:00.0: irq 119 for MSI/MSI-X [ 3.678239] mlx4_core 0000:07:00.0: irq 120 for MSI/MSI-X [ 3.678243] mlx4_core 0000:07:00.0: irq 121 for MSI/MSI-X [ 3.678247] mlx4_core 0000:07:00.0: irq 122 for MSI/MSI-X [ 3.678250] mlx4_core 0000:07:00.0: irq 123 for MSI/MSI-X [ 3.678254] mlx4_core 0000:07:00.0: irq 124 for MSI/MSI-X [ 3.678259] mlx4_core 0000:07:00.0: irq 125 for MSI/MSI-X [ 3.678263] mlx4_core 0000:07:00.0: irq 126 for MSI/MSI-X [ 3.678267] mlx4_core 0000:07:00.0: irq 127 for MSI/MSI-X [ 3.678271] mlx4_core 0000:07:00.0: irq 128 for MSI/MSI-X [ 3.678275] mlx4_core 0000:07:00.0: irq 129 for MSI/MSI-X
This is just the core driver; at this point additional modules are needed to do anything useful. You can manually load the modules with modprobe but sooner or later it is better to make sure they’re loaded automatically by adding their names to /etc/modules. The modules you want to load are :-
- mlx4_ib
- ib_umad
- ib_uverbs
- ib_ipoib
This is a minimal set necessary for networking (“IP”) rather than additional features such as SCSI. It’s generally better to start with a minimal set of features initially. At this point, it is generally a good idea to reboot to verify that things are getting closer. After a reboot, you should have one or more new network interfaces listed by ifconfig :-
ib0 Link encap:UNSPEC HWaddr 80-00-00-48-FE-80-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ib1 Link encap:UNSPEC HWaddr 80-00-00-49-FE-80-00-00-00-00-00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Despite the appearance, we still have quite a way to go yet. The next step is to install some additional packages: ibutils, infiniband-diags, and opensm. The last package is for a subnet manager which is unnecessary if you have an InfiniBand switch (but I don’t). The first step is to get opensm up and running. Edit /etc/default/opensm and change the PORTS variable to “ALL” (unless you want to restrict the managed ports, and make things more complicated). And start opensm: /etc/init.d/opensm start; update-rc.d opensm defaults.
At this point, you can configure the network addresses by editing /etc/network/interfaces. If you need help doing this, then you’re in the tech pool beyond your depth! Without something at the other end, these interfaces won’t work (obviously), so it’s time to start work on the other end …
Configuring FreeBSD
See: https://wiki.freebsd.org/InfiniBand I hadn’t had cause to build a custom kernel before, so the very first task was to use subversion to checkout a copy of the FreeBSD source code :-
svn co svn://svn0.us-east.FreeBSD.org/base/stable/9 /usr/src
Updating will of course require just: cd /usr/src && svn update. Once installed, create a symlink from /sys to /usr/src/sys if the link does not already exist: ln -s /usr/src/sys /sys
Go to the kernel configuration directory (/usr/src/sys/amd64/conf), copy the GENERIC configuration file to a new file, and edit the new file to add in certain options :-
# Infiniband stuff (locally added) options OFED options IPOIB_CM device ipoib device mlx4ib
Again, this is a minimal set that will not offer full functionality … but should be enough to get IP networking up and running. The next step is to build and install the kernel :-
make buildkernel KERNCONF=${NAME-OF-YOUR-CONFIG}; NAME-OF-YOUR-CONFIG}make installkernel KERNCONF=${
The next step is to build the “world” :-
- Edit /etc/src.conf and add “WITH_OFED=’yes'” to that file.
- Change to /usr/src and run: make buildworld
- Finalise with make installworld
As it happens I had to build the user-land first, as the kernel compilation needed a new user-land feature.
After a reboot, the new network interface(s) should show up as ib0 upwards. And these can be configured with an address in exactly the same as any other network interface.
Testing The Network
A tip for making sure the interfaces you think are connected together is to configure one of the machines, send a broadcast ping to the relevant network address of each interface in turn, and run tcpdump on the other machine to verify that the packets coming down the wire match what you expect.
Below the level of IP, it is possible to run an InfiniBand ping to verify connectivity. First you need a GUID on “the server”, which can be obtained by running ibstat and looking for the “Port GUID”, which will be something like “0x0002c90200273985”. Next run ibping -S on the server.
Now on the other machine (“the client”), run ibping :-
# ibping -G 0x0002c90200273985 Pong from polio.inside.zonky.org (Lid 3): time 0.242 ms Pong from polio.inside.zonky.org (Lid 3): time 0.153 ms Pong from polio.inside.zonky.org (Lid 3): time 0.160 ms
The next step is to run an IP ping to one of the hosts. If that works, it is time to start looking at something that will do a reasonable attempt at a speed test.
This can be done in a variety of different ways, but I chose to use nttcp which is widely available. On one of the hosts, run nttcp -i to act as the “partner” (or server). On the sending server, run nntcp -T ${ip-address-to-test} which will give output something like :-
# nttcp -T 10.0.0.26
Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s
l 8388608 0.70 0.01 95.7975 5592.4053 2048 2923.51 170666.7
1 8388608 0.71 0.04 94.0667 1878.6950 5444 7630.87 152403.3
According to the documentation, the second line should begin with ‘r’, but for a simple speed test we can simply average the numbers in the “Real-MBit/s” to get an approximate speed. Oddly my gigabit ethernet seems to have mysteriously degraded to 100Mbps! At least it makes the InfiniBand speed slightly more impressive :-
# nttcp -T 10.255.0.2
Bytes Real s CPU s Real-MBit/s CPU-MBit/s Calls Real-C/s CPU-C/s
l 8388608 0.03 0.00 2521.9415 16777.2160 2048 76963.55 512000.0
1 8388608 0.03 0.03 2206.6574 2568.6620 4032 132579.25 154329.0
Before getting into a panic over what appears to be a pretty poor result, it is worth bearing in mind that IP over InfiniBand isn’t especially efficient, and InfiniBand seems to suffer from marketing exaggeration. From what I understand, DDR’s 20Gbps signalling rate becomes 16Gbps, which in turn becomes 8.5Gbps when looking at the output of ibstatus (not ibstat) – why the halving here is a bit of a mystery, but that may become apparent later.
There has also been a hint that FreeBSD is due for a significant improvement in InfiniBand performance sometime after the release of 9.2.
As a late addition, it would appear that running OpenSM (the subnet manager) on both hosts means that when one or other is rebooting, the other can take over the duties of the subnet manager. To enable on FreeBSD, simply add opensm_enable=”YES” to the file /etc/rc.conf and reboot.