Adventures in fibre channel over ethernet. This is a draft so can be said to have errors for now.

device that requires access to a remote block store over FCoE or iSCSI
device that provides the block storage to remote initiators

Here we assume target device has a MAC Address of ac:de:48:23:45:67 on int0 and the initiator of 00:00:5e:00:53:00 on eth0.

AS a first step, have unlocked the max MTU on the involved interfaces

It does seem to be legitimate to run FCoE on a brctl bridge as it is just another set of ethertypes

Let’s Begin

on target, install the targetcli

  1. apt-get install targetcli

may not be needed for vn2vn

  1. apt-get install lldpad fcoe-utils

on target, we will run targetcli and export a LVM2 logical volume called fcoetest

  1. # targetcli
  2. /backstores/iblock create name=fcoetest dev=/dev/lvm2_groupname/fcoetest
  1. fcoeadm -c int0

creates entry in /sys/class/fc_host/

now can do:

  1. cat /sys/class/fc_host/host*/port_name

We now can set up access to the LUN effectively to the other mac address

  1. /tcm_fc create 20:00:ac:de:48:23:45:67
  2. /tcm_fc/20:00:ac:de:48:23:45:67/luns create /backstores/iblock/fcoetest
  3. /tcm_fc/20:00:ac:de:48:23:45:67/acls create 20:00:00:00:5e:00:53:00

To redo this, we can /tcm_fc delete 20:00:ac:de:48:23:45:67

Complete a step not done by fcoe-utils tools dpkg ☺

  1. echo org.open-fcoe.libhbalinux /usr/lib/libhbalinux.so.2.0.2 >> /etc/hba.conf
  1. /> ls
  2. o- / [...]
  3. o- backstores [...]
  4. | o- fileio [0 Storage Object]
  5. | o- iblock [1 Storage Object]
  6. | | o- fcoetest [/dev/stat/fcoetest activated]
  7. | o- pscsi [0 Storage Object]
  8. | o- rd_dr [0 Storage Object]
  9. | o- rd_mcp [0 Storage Object]
  10. o- iscsi [0 Target]
  11. o- loopback [0 Target]
  12. o- tcm_fc [1 Target]
  13. o- 20:00:ac:de:48:23:45:67 [enabled]
  14. o- acls [1 ACL]
  15. | o- 20:00:00:00:5e:00:53:00 [1 Mapped LUN]
  16. | o- mapped_lun0 [lun0 (rw)]
  17. o- luns [1 LUN]
  18. o- lun0 [iblock/fcoetest (/dev/stat/fcoetest)]

If all is satisfactory, use /saveconfig to keep the settings

Setup success!

The default wanted a so-called fcf device, which we will call a special kind of ethernet forwarder. Not got one of those.

We want vn2vn mode which means we can generally do FCoE between 2 ordinary computers with ethernet interfaces, the only need here is zero frame loss.

Now modprobe fcoe on initiator and targets and tell them where to do “create_vn2vn” or stop doing “destroy” FCoE, the same step is done on both ends, though the target also had the access control rules setup as above with targetcli.

Might also run into, problem: Unknown value type 'fc_wwn' Temporarily edited config.py and utils.py to suppress warning and treat as valid.

  1. echo eth0 > \
  2. /sys/module/libfcoe/\
  3. parameters/create_vn2vn
  4. echo eth0 > \
  5. /sys/module/libfcoe/\
  6. parameters/destroy
  7. echo int0 > \
  8. /sys/module/libfcoe/\
  9. parameters/create_vn2vn
  10. echo int0 > \
  11. /sys/module/libfcoe/\
  12. parameters/destroy

Set permission on the block devices to access from the userspace, and then read and write octets with hexedit. The long term intention is to put a distributed cluster filesystem on it, the block should be proven stable first though.

  1. setfacl -m u:user:rwX /dev/disk/by-path/pci-0000:04:00.0-fc-0x2000acde48234567-lun-0
  2. hexedit /dev/disk/by-path/pci-0000:04:00.0-fc-0x2000acde48234567-lun-0

But its slow, was it because fcoeadm -l says "MaxFrameSize: 2112", first thought was to make this bigger but it turns out this is by FC design. It is time to set up iSCSI to compare performance

iSCSI Setup for comparison

Again, in targetcli, we setup a comparable iSCSI setup with the same LUN as for FCoE

  1. /iscsi create iqn.2000-01.arpa.ip6
  2. .f.e.
  3. .a.e.d.e.4.8.f.f.f.e.
  4. luns/ create /backstores/iblock/fcoetest
  5. acls/ create value from initiator /etc/iscsi/initiatorname.iscsi
  6. portals/ create 2001:db8::aede:48ff:fe23:4567
  7. set attribute authentication=0 demo_mode_write_protect=0

For iSCSI the lun acces is set target to wwn in/etc/iscsi/initiatorname.iscsi of initiator

  1. TARGETIP=2001:db8::aede:48ff:fe23:4567
  2. WWN=`iscsiadm -m discovery -t sendtargets -p ${TARGETIP} | cut -d" " -f2`
  3. iscsiadm --mode node --targetname "${WWN}" --portal [${TARGETIP}]:3260 --login

Let’s race FCoE and iSCSI!

  1. setfacl -m u:user:rwX /dev/disk/by-path/\
  2. ip-2001:db8::\
  3. aede:48ff:fe23:4567:3260-iscsi-\
  4. iqn.2000-01.arpa.ip6
  5. .f.e.
  6. .a.e.d.e.4.8.f.f.f.e.
  7. dd if=/dev/zero of=/dev/disk/by-path/\
  8. pci-0000:04:00.0-fc-0x2000acde48234567-lun-0
  9. dd if=/dev/zero of=/dev/disk/by-path/\
  10. ip-2001:db8::\
  11. aede:48ff:fe23:4567:3260-iscsi-\
  12. iqn.2000-01.arpa.ip6
  13. .f.e.
  14. .a.e.d.e.4.8.f.f.f.e.

At this point it was expected that FCoE would outpace iSCSI but it went very wrong. iSCSI was in lead by far, and the cause must be thought to be dropped frames, somewhere… Time to find out why.

Let’s capture!

Here is a tcpdump string for wireshark ether proto 0x8906 or tcp port 3260 we can watch iSCSI and FCoE together

Using dropwatch there were signs of trouble already:

  1. /usr/src/linux-source-3.2/net/packet/af_packet.c: packet_rcv_spkt+de, tpacket_rcv+6a5
  2. /usr/src/linux-source-3.2/net/core/dev.c: net_tx_action+0

Stress testing the ethernets

A packet injector is used to create a flood of frames as fast as we can.

There are published adjustments to reduce the possibility that core drops frames:

  1. # make the RX buffers bigger
  2. net.core.optmem_max = 50000
  3. net.core.netdev_max_backlog = 100000
  4. # make the tx buffer bigger
  5. ifconfig eth0 txbuffer 10000

Let’s test!

  1. ./packETHcli -i eth0 -m 2 -d -1 -n 0 -f cec &

What we still drop frames?!

RTL8169 Issues

It turns out that frames are dropped in rtl8169 driver, though this was not declared in the ifconfig output as actually the NIC drops them as “rx_missed” due to the driver not processing frames efficiently enough.

  1. ethtool -S eth0

rx_missed ?!

Make the interrupt handler do more work maybe, 64 is not big enough?

It was said that realteks can hold up to 1024 frames before they drop so lets empty up to that many per RX interrupt

  1. sysctl net.core.dev_weight=1024

It turns out to really improve rtl8169.ko we must hack source, users can recompile just the modules to be patched.

The secret is that _rx_interrupt does rather lot of work via memcpy of whole frames and we remove that, instead rotating the RX ring pointers as frames are received.

If we remove that then it should be faster, we can preallocate frames to mtu during driver initialisation, and alter pointers in the RX ring buffer as frames are moved from the ring into linux networking via skb_put etc.

One side effect is we do use more precious kernel memory, and use too much and system crash, so we compromise on enough to go drop-free.

The moment we've been waiting for

With adjusted rtl8169 driver, FC perfomance approaches that of iSCSI and other applications like NFS seem to benefit from less droppiness.

  1. # iscsi
  2. 131073+0 records in
  3. 131072+0 records out
  4. 67108864 bytes (67 MB) copied, 16.4312 s, 4.1 MB/s
  5. # fcoe
  6. dd if=/dev/urandom of=/dev/disk/by-path/pci-0000:04:00.0-fc-0x2000acde48234567-lun-0 bs=$((1024*4))
  7. dd: writing `/dev/disk/by-path/pci-0000:04:00.0-fc-0x2000acde48234567-lun-0': No space left on device
  8. 16385+0 records in
  9. 16384+0 records out
  10. 67108864 bytes (67 MB) copied, 7.79058 s, 8.6 MB/s

GFS2 adventures

  1. /loopback/ create?
  2. naa.2000acde48234567
  3. /loopback/
  4. naa.2000acde48234567/luns/ create /backstores/iblock/fcoetest