10G дома: Infiniband + FreeBSD

Я тут интересовался про Infiniband и FreeBSD, теперь могу и сам рассказать :)

Datagram mode

Для начала нужна FreeBSD 9. У меня - какая-то, cvsup делал где-то в январе или около того.

Далее все тривиально:

/etc/make.conf:

WITH_OFED=yes
Конфиг ядра (в GENERIC это место не включено) /sys/amd64/conf/OFED:
include GENERIC
options OFED # Infiniband protocol stack and support
options SDP # Sockets Direct Protocol for infiniband
device ipoib # IP over IB devices
device mlx4ib # ConnectX Infiniband support
device mlxen # ConnectX Ethernet support
device mthca # Infinihost cards
У меня карты mthca, остальные два драйвера в моем случае вероятно не нужны.

Далее все просто:

cd /usr/src
make buildworld && make installworld # поставит IB-шный утиль, всякие ibstat и opensm
make buildkernel KERNCONF=OFED && make installkernel KERNCONF=OFED

Что-то из этого добра (то ли userland IB-шный, то ли ядро) не собирается clang-ом, поэтому про CC=clang стоит забыть.

Если нужен Subnet manager (на другом конце линка/свитче его нет), то opensm_enable=YES в rc.conf (а если нету /etc/rc.d/opensm, то накатить его mergemaster-ом).

Бутимся....

ib_mthca0: HCA FW version 5.1.000 is old (5.3.000 is current).
ib_mthca0: If you have problems, try updating your HCA FW.
ib0: Attached to mthca0 port 1
ib1: Attached to mthca0 port 2
Фирмварь, да, надо поапгрейдить наверное....

Ну и прочего:

$ ibstat
CA 'mthca0'
        CA type: MT25208
        Number of ports: 2
        Firmware version: 5.1.0
        Hardware version: a0
        Node GUID: 0x0002c9020021f814
        System image GUID: 0x0002c9020021f817
        Port 1:
                State: Active
                Physical state: LinkUp
                Rate: 10
                Base lid: 1
                LMC: 0
                SM lid: 1
                Capability mask: 0x02510a6a
                Port GUID: 0x0002c9020021f815
        Port 2:
                State: Active
                Physical state: LinkUp
                Rate: 10
                Base lid: 6
                LMC: 0
                SM lid: 3
                Capability mask: 0x02510a6a
                Port GUID: 0x0002c9020021f816
$ ifconfig ib0
ib0: flags=8043<UP,BROADCAST,RUNNING,MULTICAST> metric 0 mtu 2044
        options=80018<VLAN_MTU,VLAN_HWTAGGING,LINKSTATE>
        lladdr 0.0.4.4.fe.80.0.0.0.0.0.0.0.2.c9.2.0.21.f8.15
        inet 10.10.10.129 netmask 0xffffff80 broadcast 10.10.10.255
        inet6 fe80::e2cb:4eff:fe35:15d7%ib0 prefixlen 64 scopeid 0xe
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
C виндой по IPoIB работает, самба на больших файлах ложится на ту полку, какую диски могут отдать (180-250MB/sec на запись, 200-320 на чтение, как звезды лягут и фрагментация на дисках).

Всякие iperf и подобное - пока не щупал, времени не было на это. Может быть, сегодня.

Тут спрашивали про Linux, связка FreeBSD-Linux тоже работает, никаких проблем, пинги пингают, в интернет ходит, все остальное (втч. перформанс) не успел попробовать.

Короче, в Datagam mode проблем нет.

Connected mode

А вот с Connected mode все наоборот, добиться нормальной работы не удалось.

Добавляем в ядро:

options IPOIB_CM # Use connect mode ipoib
Собираем, ставим, перегружаемся.

MTU у интерфейсов становится правильным, 65520. Но счастья это не приносит, в логах и на консоли вот такое:

Feb 26 19:57:59 home-gw kernel: ib0: packet len 6416 (> 2044) too long to send, dropping
Feb 26 19:58:00 home-gw kernel: ib0: packet len 8684 (> 2044) too long to send, dropping
Feb 26 19:58:09 home-gw last message repeated 7 times
Feb 26 19:58:18 home-gw kernel: ib0: packet len 8723 (> 2044) too long to send, dropping
Рассматривание исходников какбэ говорит нам, что Connected Mode надо еще включить. В Linux это включается вот так:
echo connected >`find /sys -name mode | grep ib0`
В FreeBSD нету /sys. Правда есть sysctl sys.class, который весь про infiniband, но мне не удалось найти там ни строчки про Connected mode. Гугление пока тоже не дало результата, буду пробовать еще, равно как и читать исходники драйверов.

Пробовал, естественно, и ifconfig link0...link2 (больше в голову ничего не пришло), тоже не помогло.

Comments

первая ссылка в гугле говорит

options IPOIB_CM # Use connect mode ipoib

а, плохо читал

судя по сырцам CM должна включаться при ините девайса, если поддержка есть.

ключевые слова

ipoib_transport_dev_init, ipoib_cm_dev_init, IPOIB_FLAGS_RC

я не очень внимательно сырцы посмотрел, то похоже эта ошибка исключительно от mtu.
причем в двух местах, в одном от mcast_mtu.

которое как-то сложно ставится. похоже оно после добавлерния порта не меняется.

в /usr/src/sys/ofed/drivers/infiniband/ulp/ipoib/ipoib_main.c есть такой кусок:

if (ipoib_cm_get(path) && ipoib_cm_up(path)) {
ipoib_cm_send(priv, mb, ipoib_cm_get(path));
} else if (path->ah) {
ipoib_send(priv, mb, path->ah, IPOIB_QPN(eh->hwaddr));
} else if ((path->query || !path_rec_start(priv, path)) &&
path->queue.ifq_len < IPOIB_MAX_PATH_REC_QUEUE) {
_IF_ENQUEUE(&path->queue, mb);
} else {
++priv->dev->if_oerrors;
m_freem(mb);
}

ipoib_send проверяет по mcast_mtu, ipoib_cm_send -- по нормальному mtu, но диагностика у них одинаковая. поправь в сырцах что бы было понятно кто ругается. после этого можно попытаться понять чего не хватает -- path в cm, CM_REP_ATTR_ID от винды (если я правильно понял)

По моим ощущениям (сугубо музыкой навеяных), не хватает ему ipoib_cm_up

Проверять буду, но постепенно, сервер то боевой.

Напихал я туда отладочной печати. Вот в этом месте (ipoib_main.c)
if (ipoib_cm_get(path) && ipoib_cm_up(path)) {
ipoib_cm_send(priv, mb, ipoib_cm_get(path));
} else if (path->ah) {

ipoib_cm_up(..) возвращает 0

А дальше я там запутался. Т.е. докопался до того, что должен прийти event CM_REQ_RECEIVED, только вот кто должен бы его послать?
на винде up-down интерфейсу делал - не помогает.

Пока наплевал, в-общем.

идиотское предположение -- а не следует ли после изменения MTU рестартовать opensm?
ну и MTU на винде не надо трогать?

На винде если я включаю connected mode, то интерфейс делает up-down и MTU новое.
OpenSM можно попробовать рестартовать, но винда-линукс работали без этого. И на FreeBSD-шной стороне я mtu никак не меняю т.е. OpenSM стартует при уже большом MTU

Меня вот удивляет, что в линуксе/винде надо это место специально включать, а тут оно вроде как "само".

Но да, попробую всячески пошаманить еще. Не сегодня.

А вот между тем две FreeBSD (одинаковые т.к. склонированы dump/restore) не стали друг друга любить по IB даже в datagram mode. При том, что кабели/карты гарантированно хорошие, на той же паре портов/кабеле пара FreeBSD+Windows живет.

Причем, два вида грабель
1) ARP не ходит. Т.е. на одной машине я вижу запрос, вижу ответ в tcpdump, а на второй не вижу ответа.
2) Если кабель ткнуть-выткнуть и/или рестартовать opensm - ARP появляется. Тогда на одной машине пингую, на второй вижу icmp request и reply, но reply не получается.

Не знаю что и думать пока.

каменту расскринь, да?

Communication Management encompasses the protocols and mechanisms
used to establish, maintain, and release channels for the IB Reliable
Connection, Unreliable Connection, and Reliable Datagram
transport service types. The Service ID Resolution Protocol (see section
12.11) enables users of Unreliable Datagram service to locate Queue
Pairs supporting their desired service.
Connections are managed over Queue Pairs other than those used for the
connection, through the protocol described herein, between the Communication
Managers (CMs) on each system. (See Figure 128) The CMs
communicate using Management Datagrams (MADs), typically over the
General Services Interface (GSI) on each system. This document defines
CM external behaviors, but internal interfaces and implementations are
outside the scope of the InfiniBandTM Architecture specification. Examples
are intended to enable understanding, not to specify implementation.

я просто оставлю это здесь (тм)

Table 315 Communication Management Attributes

Attribute NameAttribute IDAttribute-Modifier Description
ClassPortInfo 0x0001 0x00000000 Refer to 13.4.8.1 ClassPortInfo on page 741
ConnectRequest 0x0010 0x00000000 Refer to 12.6.5 REQ - Request for Communication on page
666
MsgRcptAck 0x0011 0x00000000 Refer to 12.6.6 MRA - Message Receipt Acknowledgment
on page 668
ConnectReject 0x0012 0x00000000 Refer to 12.6.7 REJ - Reject on page 669
ConnectReply 0x0013 0x00000000 Refer to 12.6.8 REP - Reply to Request for Communication
on page 675

Ну вот кто должен это послать и почему?
tcpdump-а у них нет, а debug print на живом сервере как-то мучительно.

Пусть поживет, как-нибудь руки дойдут и изучу (а наверное проще всего в рассылке спросить :)

Однако в 9.0-RELEASE CM поднялся, но заработал на MTU 16K, выше пробовал 32К - отрицательно.
Наблюдаю забавную вещь

На исходящем интефейсе трафа в два раза больше чем на входе (размер пакета в 2 раза больше MTU):
Исходящий:

packets errs idrops bytes packets errs bytes colls
48793 0 0 2732681 73186 0 2396998518 0
48800 0 0 2732824 73204 0 2397211500 0
49008 0 0 2744462 73509 0 2407361682 0
48711 0 0 2728093 73084 0 2393230398 0
48868 0 0 2736908 73288 0 2400222446 0
48768 0 0 2731022 73152 0 2395655054 0
48618 0 0 2722885 72931 0 2388253546 0
48845 0 0 2735330 73271 0 2399470382 0
48875 0 0 2737300 73303 0 2400682750 0
22799 0 0 1276774 34190 0 1119561806 0

Входящий:

packets errs idrops bytes packets errs bytes colls
72976 0 0 1194181818 48638 0 6421098 0
73200 0 0 1197833099 48809 0 6442244 0
72877 0 0 1192562618 48587 0 6413226 0
72750 0 0 1190485284 48502 0 6402082 0
72774 0 0 1190845565 48502 0 6403222 0
72508 0 0 1186539290 48349 0 6381354 0
72807 0 0 1191418206 48536 0 6406950 0

Из-за чего может быть? Наблюдается как в CM, так и в RM.

А CM поднялся между кем и кем? На одной стороне FreeBSD, а на другой?

И есть ли свитч?

6 машин с FreeBSD, между ними свич.

Ага, спасибо. Subnet Manager - в свитче?

А про входящий/исходящий я не понял вопроса. Вроде колонка in сходится с колонкой out второго вывода (я так понял, это же две машины)? Ну и наоборот.

А, потом понял. Счетчик байтов не сходится. Ну значит пролюбили где-то подсчет для фрагментированных пакетов.

Нет, без OpenSM линк не поднимался, видимо в свиче нету. простенький он, unmanaged.
Ну как же сходится, если на исходе мы видим 20 гигабит аута, с размером пакета 32К, а на входе 10 гигабит входа, с размером пакета 16К.

Да, я уже поправился.

Осталось понять, кто считает байты на интерфейсе (я - не знаю). Может для фрагментированных на входе забыли посчитать (для фрагментов)

netstat -w 1 -I ib0

Не, это понятно.

А в интерфейсном счетчике откуда берутся значения? Кто их туда кладет, драйвер карты или что-то такое более общее, единое на весь стек?

Я не знаю, потому и спрашиваю. Если драйвер карты, то нет ли там банальной баги в этом подсчете....

Натолкнул на мысль :)
Поснифал, пакеты идет с length 16316.
Осталось выяснить кто нас так жестоко поимел.