ETegro_Technologies 26 фев 2014 в 05:55

Производительность 40G Ethernet с коммутатором на основе Intel ONS

5 мин

19K

Блог компании ETegro Technologies

+20

Комментарии 50

maksasila 26 фев 2014 в 08:34

А зачем MPI? Есть netperf (TCP) и ib_write_bw (RoCe). И для сравнения, можно было бы выложить back to back (без коммутатора) тесты.

ETegro_Technologies 26 фев 2014 в 09:59

$ ib_write_bw -F
— RDMA_Write BW Test
Dual-port: OFF Device: mlx4_0
Number of qps: 1 Transport type: IB
Connection type: RC Using SRQ: OFF
CQ Moderation: 100
Mtu: 2048[B]
Link type: Ethernet
Gid index: 0
Max inline data: 0[B]
rdma_cm QPs: OFF
Data ex. method: Ethernet
— local address: LID 0000 QPN 0x00d7 PSN 0xc71fec RKey 0xa0010519 VAddr 0x007fcb10e0c000
GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:142:192
remote address: LID 0000 QPN 0x00f2 PSN 0x3d2abe RKey 0xa8010519 VAddr 0x007f62d588f000
GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:143:96
— #bytes #iterations BW peak[MB/sec] BW average[MB/sec] MsgRate[Mpps]
65536 5000 4565.82 4565.73 0.073052
— $ ib_write_lat -F
— RDMA_Write Latency Test
Dual-port: OFF Device: mlx4_0
Number of qps: 1 Transport type: IB
Connection type: RC Using SRQ: OFF
Mtu: 2048[B]
Link type: Ethernet
Gid index: 0
Max inline data: 220[B]
rdma_cm QPs: OFF
Data ex. method: Ethernet
— local address: LID 0000 QPN 0x00da PSN 0x9127b4 RKey 0xb8010519 VAddr 0x00000001b16000
GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:142:192
remote address: LID 0000 QPN 0x00f3 PSN 0xed6e66 RKey 0xb0010519 VAddr 0x000000014fd000
GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:143:96
— #bytes #iterations t_min[usec] t_max[usec] t_typical[usec]
Conflicting CPU frequency values detected: 1200.000000 != 2801.000000
Test integrity may be harmed!
Warning: measured timestamp frequency 2789.35 differs from nominal 1200 MHz
2 1000 1.56 16.90 1.76
---------------------------------------------------------------------------------------

ETegro_Technologies 27 фев 2014 в 13:23

Так чуть быстрее получилось.

$ ib_write_bw -R -F -s 4194304
— RDMA_Write BW Test
Dual-port: OFF Device: mlx4_0
Number of qps: 1 Transport type: IB
Connection type: RC Using SRQ: OFF
CQ Moderation: 100
Mtu: 2048[B]
Link type: Ethernet
Gid index: 0
Max inline data: 0[B]
rdma_cm QPs: ON
Data ex. method: rdma_cm
— Waiting for client rdma_cm QP to connect
Please run the same command with the IB/RoCE interface IP
— local address: LID 0000 QPN 0x0219 PSN 0x9c52ef
GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:143:96
remote address: LID 0000 QPN 0x0201 PSN 0xb490d7
GID: 254:128:00:00:00:00:00:00:02:02:201:255:254:236:142:192
— #bytes #iterations BW peak[MB/sec] BW average[MB/sec] MsgRate[Mpps]
4194304 5000 4671.96 4671.96 0.001168
---------------------------------------------------------------------------------------

Egorkkk 26 фев 2014 в 09:05

<оффтоп> А не подскажете ли честный 10ГБ коммутатор портов этак на 16? </оффтоп>

maksasila 26 фев 2014 в 09:12

Есть 8 портов у HP, по-моему.

ETegro_Technologies 26 фев 2014 в 10:06

Есть у всяких Netgear.

JDima 26 фев 2014 в 17:01

Ну раз уж пиарите свитч и ASIC — как в нем реализован QoS, и, в частности, как боретесь с head of line blocking? Серьезная проблема для многих cut-through свитчей, способная сильно нагадить.

ETegro_Technologies 26 фев 2014 в 18:53

Интел клянется, что их езернет самый lossless из всех езернетов.

Патенты публикуют, что все доступные Efficient means to provide back pressure without head of line blocking используются.

JDima 26 фев 2014 в 19:24

Ну положим в FCoE для lossless главное — вовремя сообщить назад «хорош пакеты слать, подожди немного», даже когда всего один перегруженный в исходящем направлении интерфейс мешает трафику ходить между совершенно другими интерфейсами. Дропов-то не будет, PFC отработает, вот только скорость просядет жестоко…

А патент, по-моему, описывает store-and-forward архитектуру. Да и вообще, у вас там что, совсем никакой документации нет, если патентами кидаетесь, которые опубликованы 15 лет назад? :) Честно, мне впервые дали ссылку на патент в ответ на просьбу рассказать про архитектуру :)

Ну да, в патенте говорится про VOQ, вполне нормальное решение, только интересно, относится ли оно к данному чипу и сколько там очередей.

ETegro_Technologies 27 фев 2014 в 13:21

Fulcrum (оригинальный разработчик чипа) ставил одной из целей — избавиться от head of line blocking.
У них это получилась еще в первом коммерческом продукте в 2003 году.

JDima 27 фев 2014 в 14:55

Я в недоумении. Честно. Вроде простой вопрос. Вы вовсю пиарите ~~мир дружбу жвачку~~ опенсорс и SDN, открытость и т.д., и при этом не можете найти ответ на простой архитектурный вопрос :)

5 секунд в гугле находят аналогичную информацию по напрочь проприетарному и кроваво-ентерпрайзному цискиному нексусу 5500:

Скрытый текст

The Cisco Nexus 5500 platform implements virtual output queues (VOQs) on all ingress interfaces, so that a congested egress port does not affect traffic directed to other egress ports. Every IEEE 802.1p class of service (CoS) uses a separate VOQ in the Cisco Nexus 5500 platform architecture, resulting in a total of 8 VOQs per egress on each ingress interface, or a total of 384 VOQs per ingress interface on the Cisco Nexus 5548P, and a total of 768 VOQs per ingress interface on the Cisco Nexus 5596. The extensive use of VOQs in the system helps ensure high throughput on a per-egress, per-CoS basis. Congestion on one egress port in one CoS does not affect traffic destined for other CoSs or other egress interfaces, thus avoiding head-of-line (HOL) blocking, which would otherwise cause congestion to spread.

А варианты разные. Можно было бы сделать, например, сэконосить и сделать по одному VoQ на порт-группу без разделения по COS. Этого было бы, наверное, достаточно для маркетингового заявления «мы избавились от head of line blocking», но это не совсем соответствовало бы реальности.

И я сильно сомневаюсь, что в 2003-м году где-то были сотни очередей на входящий порт…

ETegro_Technologies 27 фев 2014 в 15:41

Интел не экономил.

By providing full bandwidth access to every output queue from every input port, no blocking occurs within the switch, eliminating the need for complex VoQs and schedulers.

JDima 28 фев 2014 в 17:11

With the Intel®Ethernet Switch Family, all packets arriving at any ingress port are immediately queued at full line rate into shared memory. Packets are then scheduled from shared memory to the egress ports.

По-моему, это описание чего угодно кроме cut-through архитектуры (если пакет сначала всегда копируется в shared memory). Или я не прав?

ETegro_Technologies 28 фев 2014 в 19:18

Для cut-through достаточно, чтобы процесс передачи фрейма в порт назначения начался сразу по дешифровке адреса назначения.
Получил-расшифровал адрес-кинул в буфер на выдачу.
Особых противоречий не вижу.

JDima 1 мар 2014 в 14:09

Погодите… Cut-through — это когда хвост пакета торчит из одного порта свитча, а первые байты уже покидают другой. Понятно, что когда исходящий интерфейс уже занят, надо без вариантов поместить пакет в буфер, но тут вроде как говорится о том, что все пакеты попадают в буфер, т.е. мы говорим о store-and-forward. Архитектура чем-то схожа с таковой у того же cat4948, у которого тоже единый shared buffer под всё.

ETegro_Technologies 1 мар 2014 в 19:41

Store-and-forward сначала закидывает пакет в буфер, потом разбирается, что с ним делать.

JDima 2 мар 2014 в 07:16

Так указанный свитч cut-through или store-and-forward?

ETegro_Technologies 2 мар 2014 в 09:34

Интел заявляет, что cut-through.
Сначала выясняет, что за пакет, потом отправляет по назначению. По латентности матрицы это видно.

JDima 2 мар 2014 в 17:09

Интел заявляет, что cut-through.

Верю. Так про архитектуру где почитать, если указанное выше явно относится к каким-то другим store and forward чипам (которые сначала полностью буферизируют пакет)? :)

По латентности матрицы это видно.

По абсолютным цифрам тяжело ориентироваться. Надо смотреть увеличение задержки с ростом размера пакета. Если увеличения нет или почти нет, то явно cut-through.

ETegro_Technologies 2 мар 2014 в 18:05

При cмене размера кадра с по умолчанию на 9К латентность увеличилась процентов на 10-15.

JDima 2 мар 2014 в 18:13

Такие вещи мерить компьютерами бесперспективно. Гонялись ли тесты с участием специализированных железяк вроде Spirent TestCenter для генерации и приема трафика? По-моему, вендор просто обязан иметь несколько таких девайсов, они позволяют исключить искажения результата на стороне сетевух, сетевого стека ОС, приложений и т.д., сконцентрировавшись на самом тестируемом оборудовании.

iavael 26 фев 2014 в 23:17

> В процессе подготовки выяснился нюанс адаптеров Mellanox — они требуют принудительного перевода в режим Ethernet. Заявленный функционал автоматического определения типа подключенной сети почему-то не работает, может поправят.

Это потому что в скриптах инициализации по-дефолту ставится режим IB у интерфейсов, что весьма правильно, поскольку настройки на серверах все равно сильно зависят от выбранного протокола.

ETegro_Technologies 27 фев 2014 в 11:37

Обещают же auto-negotiation.
Написали бы — ставить вручную, то вопрос бы не возник.

iavael 26 фев 2014 в 23:26

И, кстати, при сравнении 40GE и 40G IB надо помнить, что у эзернета 40G — это net data rate, а у IB — gross data rate (кодирование такое же, как и у ethernet — 8b/10b).

И еще с IB есть такой нюанс, что IPoIB медленный (от 2 до 10 гигабит в секунду для 40G), дает большую нагрузку на ЦП, а также сильно зависит от используемого MTU и типа QP (от 2k для UD до 64к RC).

horridum 27 фев 2014 в 05:16

А не пробовали тюнить по данному руководству? 22 ГБ/сек удалось выжать, меряли iperf'ом между двух карточек.

maksasila 27 фев 2014 в 08:00

Плохо вижимали :)
Если всё по этой инструкции + последние драйверы + Gen 3 сервер, будет 40.

ETegro_Technologies 27 фев 2014 в 12:08

22 гигабайта — это больше теоретического пика двух портов.
Может все таки гигабита?

horridum 27 фев 2014 в 12:47

Да, гигабита, конечно же

ETegro_Technologies 27 фев 2014 в 13:22

Так у нас получилось в итоге 37,4 гигабита :)

Или вы про работу через TCP стек?

horridum 27 фев 2014 в 13:31

IPoIB, connected mode.

ETegro_Technologies 27 фев 2014 в 13:34

А, вы про комментарий iavael.

iavael 27 фев 2014 в 16:26

Какой MTU? И какая получилась загрузка CPU?

horridum 28 фев 2014 в 09:53

64k — точных цифр по загрузке сейчас не вспомню, но выше 60% не поднималось на e5-2600 ксеоне. В ближайшем будущем еще буду тесты гонять — скажу точнее.

ToSHiC 27 фев 2014 в 16:55

Кстати да, про руководство. VMA пробовали включать? Мне показывали лабу, latency в одну сторону между двумя машинками падала с 9.5мкс до 1.5мкс для мелких пакетов.

amarao 27 фев 2014 в 10:33

Можно уточнить, как выглядит использование RDMA с точки зрения приложения? У нас есть программа, которая говорит

sock = socket(AF_INET, SOCK_STREAM, 0);
connect(sock, &addr, sizeof(addr))
send(sock, message, sizeof(message), 0);
recv(sock, buf, sizeof(message), 0);

Что меняется для приложения? Для ядра?

andrewsapronov 28 фев 2014 в 14:48

Выглядеть будет чуть сложнее. На OFED есть разные примеры в части RDMA, например простой клиент. Фактически тоже самое для iWARP

Для приложения меняется API. Для ядра принципиально ничего не меняется — но должны быть соответствующее оборудование, драйверы и библиотеки.

amarao 28 фев 2014 в 15:32

Ага, спасибо, я услышал главное. Меняется userspace-API для приложений, пользующихся сетью.

andrewsapronov 28 фев 2014 в 16:19

Зависит от API. Например, для приложений использующих MPI ничего не меняется.

amarao 28 фев 2014 в 20:03

MPI это, мягко говоря, экзотика. Меня интересовала её применимость с точки зрения обычных сетевых приложений. Получается не очень.

andrewsapronov 28 фев 2014 в 20:08

Как сказать, такая латентность и скорости для _обычных_ сетевых приложений тоже в общем то экзотика и далеко не всем нужны. Оборудование специфическое, ограничения по кабелям… Основные области для таких скоростей и латентности — HPC и хранение, а для них RDMA варианты основных протоколов есть давно — MPI, iSCSI, CIFS, NFS…

amarao 28 фев 2014 в 20:14

Ну, 40G уже вполне хочется. Например, когда в каком-нибудь CDN'е приходится поднимать ещё один сервер ради лишних 10-20Г на выходе, 40G выглядит интересно. Или где-нибудь в районе аггрегации.

Но, разумеется, хочется 40G нормальные маршрутизируемые интернетные, а не «хоть как-то».

iavael 2 мар 2014 в 10:29

IPoIB на маршрутизируемых в интернете значениях MTU — это лишь несколько гигабит в секунду и жор процессорного времени. И еще отдельная боль — это взаимодействие ethernet и infiniband сегментов сети, потому что, напомню, в IB свой стек протоколов, которые, чуть ли не в HCA оффлоадятся и даже IP прибит сбоку лишь для совместимости. Соответственно, ethernet-совместимых вланов, как и вообще чего-то ethernet-совместимого, нет. В одном облачном провайдере для того, чтобы отдавать клиентам именно ethernet даже пришлось изобрести свой multipoint VPN, инкапсулирующий ethernet-фреймы в IP-пакеты.
В общем, использовать IB только ради того, чтобы гонять по нему IP-трафик, почти бессмысленно.

amarao 2 мар 2014 в 19:30

тыг я не про infinyband, а про Ethernet.

ToSHiC 5 мар 2014 в 06:56

Если хочется просто воткнуть железку от мелланокса и сразу получить буст в скорости/задержке, ничего не меняя в коде — то это у них называется VMA ( ru.mellanox.com/page/software_vma?mtag=vma). Аппаратный оффлоад TCP/IP стека, уменьшает latency.

RDMA over Ethernet работает только если обе карты эзернетовские, да ещё и специальный свитч (эзернет, но от мелланокс) стоит. И код естественно переписать придётся под RDMA, а там всё по-другому (в конце презентации есть про это www.docstoc.com/docs/2705254/Introduction-to-RDMA-Programming).

Могу дать контакты их московского продажника (именно мелланоксовского, не посредника).

andrewsapronov 5 мар 2014 в 13:04

Почему эзернет должен быть именно от Меланокса? RoCE поддерживают многие производители, как устройств, так и силикона. В посте в частности речь идет о таком устройстве.

ToSHiC 5 мар 2014 в 13:07

Не должен. Знаю, что проблемы с совместимостью могут быть. Рассказываю про те комплекты, что знаю :)

phprus 1 мар 2014 в 07:18

Еще есть rsocket в возможностью подменять обычные сокеты через специальную библиотеку, подгружаемую, например, через LD_PRELOAD. Но в любом случае для работы RDMA потребуется поддержка технологии с обеих сторон соединения.

iavael 2 мар 2014 в 05:08

Библиотека зовется libsdp, но это костыль и он не дает всем примуществ RDMA.

phprus 2 мар 2014 в 05:50

Не совсем, я имел ввиду костыль под именем librspreload.so и rsocket.

А Вы можете рассказать про различные варианты API для RDMA в приложениях, с учетом их достоинств и недостатков?

iavael 2 мар 2014 в 10:05

> А Вы можете рассказать про различные варианты API для RDMA в приложениях, с учетом их достоинств и недостатков?

Я вообще админ, да и с infiniband-ом уже не работаю, потому вряд ли что-то дельное по программированию под IB могу рассказать.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий