10G дома: Infiniband + FreeBSD
Я тут интересовался про Infiniband и FreeBSD, теперь могу и сам рассказать :)
Datagram mode
Для начала нужна FreeBSD 9. У меня - какая-то, cvsup делал где-то в январе или около того.Далее все тривиально:
/etc/make.conf:
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
Далее все просто:
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: If you have problems, try updating your HCA FW.
ib0: Attached to mthca0 port 1
ib1: Attached to mthca0 port 2
Ну и прочего:
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>
Всякие iperf и подобное - пока не щупал, времени не было на это. Может быть, сегодня.
Тут спрашивали про Linux, связка FreeBSD-Linux тоже работает, никаких проблем, пинги пингают, в интернет ходит, все остальное (втч. перформанс) не успел попробовать.
Короче, в Datagam mode проблем нет.
Connected mode
А вот с Connected mode все наоборот, добиться нормальной работы не удалось.Добавляем в ядро:
MTU у интерфейсов становится правильным, 65520. Но счастья это не приносит, в логах и на консоли вот такое:
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
Пробовал, естественно, и ifconfig link0...link2 (больше в голову ничего не пришло), тоже не помогло.
Comments
первая ссылка в гугле говорит options IPOIB_CM # Use connec
первая ссылка в гугле говорит
options IPOIB_CM # Use connect mode ipoib
а, плохо читал
а, плохо читал
судя по сырцам CM должна включаться при ините девайса, если
судя по сырцам 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.
в /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_ma
Напихал я туда отладочной печати. Вот в этом месте (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 интерфейсу делал - не помогает.
Пока наплевал, в-общем.
идиотское предположение -- а не следует ли после изменения M
идиотское предположение -- а не следует ли после изменения MTU рестартовать opensm?
ну и MTU на винде не надо трогать?
На винде если я включаю connected mode, то интерфейс делает
На винде если я включаю connected mode, то интерфейс делает up-down и MTU новое.
OpenSM можно попробовать рестартовать, но винда-линукс работали без этого. И на FreeBSD-шной стороне я mtu никак не меняю т.е. OpenSM стартует при уже большом MTU
Меня вот удивляет, что в линуксе/винде надо это место специально включать, а тут оно вроде как "само".
Но да, попробую всячески пошаманить еще. Не сегодня.
А вот между тем две FreeBSD (одинаковые т.к. склонированы du
А вот между тем две FreeBSD (одинаковые т.к. склонированы dump/restore) не стали друг друга любить по IB даже в datagram mode. При том, что кабели/карты гарантированно хорошие, на той же паре портов/кабеле пара FreeBSD+Windows живет.
Причем, два вида грабель
1) ARP не ходит. Т.е. на одной машине я вижу запрос, вижу ответ в tcpdump, а на второй не вижу ответа.
2) Если кабель ткнуть-выткнуть и/или рестартовать opensm - ARP появляется. Тогда на одной машине пингую, на второй вижу icmp request и reply, но reply не получается.
Не знаю что и думать пока.
каменту расскринь, да? Communication Management encompasses
каменту расскринь, да?
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 Man
я просто оставлю это здесь (тм)
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-а у них нет,
Ну вот кто должен это послать и почему?
tcpdump-а у них нет, а debug print на живом сервере как-то мучительно.
Пусть поживет, как-нибудь руки дойдут и изучу (а наверное проще всего в рассылке спросить :)
Однако в 9.0-RELEASE CM
Однако в 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 поднялся между кем и
А CM поднялся между кем и кем? На одной стороне FreeBSD, а на другой?
И есть ли свитч?
6 машин с FreeBSD, между ними
6 машин с FreeBSD, между ними свич.
Ага, спасибо. Subnet Manager
Ага, спасибо. Subnet Manager - в свитче?
А про входящий/исходящий я не понял вопроса.
Вроде колонка in сходится с колонкой out второго вывода (я так понял, это же две машины)? Ну и наоборот.А, потом понял. Счетчик байтов не сходится. Ну значит пролюбили где-то подсчет для фрагментированных пакетов.
Нет, без OpenSM линк не
Нет, без OpenSM линк не поднимался, видимо в свиче нету. простенький он, unmanaged.
Ну как же сходится, если на исходе мы видим 20 гигабит аута, с размером пакета 32К, а на входе 10 гигабит входа, с размером пакета 16К.
Да, я уже
Да, я уже поправился.
Осталось понять, кто считает байты на интерфейсе (я - не знаю). Может для фрагментированных на входе забыли посчитать (для фрагментов)
netstat -w 1 -I ib0
netstat -w 1 -I ib0
Не, это понятно. А в
Не, это понятно.
А в интерфейсном счетчике откуда берутся значения? Кто их туда кладет, драйвер карты или что-то такое более общее, единое на весь стек?
Я не знаю, потому и спрашиваю. Если драйвер карты, то нет ли там банальной баги в этом подсчете....
Натолкнул на мысль
Натолкнул на мысль :)
Поснифал, пакеты идет с length 16316.
Осталось выяснить кто нас так жестоко поимел.