Локальная сеть Ethernet: байт-ориентированный сетевой адаптер?

Question

Это вопрос, который был приостановлен как в Network Engineering (потому что он включает в себя хост), так и в Server Fault (потому что ... я не уверен). Я надеюсь, что здесь будет больше смысла.

Во-первых, некоторые контексте. Высокочастотные трейдеры зависят от высокоскоростных сетей. In 2014 they were already working at the level of about 750 nanoseconds with 10Gb Ethernet и конкурируют за достижение более низких латентных значений, причем важны единичные наносекунды.

Удивительная вещь: кадр 10GbE занимает около 1 нс на байт. Таким образом, с момента, когда типичный сетевой адаптер начинает получать кадр, пока он не завершится, и сделает его доступным для остальных аппаратных средств, для минимального кадра прошло не менее 64 нс. Для кадра в 1500 байт прошло более 1 микросекунды. Поэтому, если вы дождались полного кадра, прежде чем начать работать над этим, вы тратите драгоценное время.

Но это именно то, что я видел каждый сетевой сетевой адаптер! Фактически, даже схемы обхода ядра, такие как DPDK или NetMap, работают с гранулярностью кадров, поэтому они никогда не достигнут латентности меньше, чем кадры.

Учитывайте, что данные в кадре Ethernet запускают 14 байт в фрейм. Если вы начали работать над этими данными, пока остальная часть кадра будет получена, вы сохраните минимум 50 нс и, возможно, в 20 раз больше. Это было бы БОЛЬШИМ преимуществом, когда вы сражаетесь за одиночные ns.

Я вижу две возможности:

1. HFTs и тому подобное, не считая потенциальный выигрыш во времени обработки данных до того, как кадр полностью получен. Кажется абсурдным: они используют FPGA для скорости, но позволяют тратить все это время ожидания?
2. Они фактически используют некоторые довольно специалиста аппаратных средств, даже по меркам DPDK

Таким образом, мои вопросы: как они это делают? Кто-нибудь знает о «байт-ориентированных» сетевых сетевых адаптерах, которые будут предоставлять единичные байты в кадре по мере их поступления? Если да, то как будет работать такой сетевой адаптер: например, представит ли он поток для пользователя? Возможно, также со своим собственным сетевым стеком/подсистемой?

---

Теперь я уже собрали некоторые типичные «что невозможно/плохой/безобразные» комментарии от вопросов в NE и SF, так что я буду превентивно ответить на них:

Вы хотите рекомендация продукта.

Нет. Если что-нибудь будет интересным, ознакомьтесь с руководством по продукту, если оно объяснит модель программирования или даст некоторое представление о том, как они получают латентность субкадра. Но цель состоит в том, чтобы узнать, как это делается.

Кроме того, я знаю о технических рекомендациях SE. Я не спрашиваю, потому что это не то, что я хочу.

Вы спрашиваете: «Почему никто этого не делает».

Нет, я заявил, что разговоры о задержках, которые являются невероятно низким для традиционных сетевых адаптеров, и Я спрашиваю, как они это делают.Я предположил две возможности, которые я подозреваю: байт-ориентированный сетевой адаптер и/или настраиваемое оборудование.

Это все еще может быть что-то другое: например, так, как они измеряют эти ~ 750 нс, фактически с момента, когда кадр становится доступным (традиционным) сетевым адаптером. Это вызовет все мои вопросы. Кроме того, это было бы удивительной потерей, учитывая, что они уже используют ПЛИС для бритья наносекундами.

Вам нужна FCS в конце кадра, чтобы узнать, действителен ли кадр.

FCS необходим, но вам не нужно его ждать. Посмотрите на спекулятивные методы и методы прогнозирования ветвлений, используемые в течение нескольких десятилетий основными процессорами: работа начинается спекулятивно по набору инструкций после ветви, и если ветвь не занята, проделанная работа просто отбрасывается. Это улучшает латентность, если спекуляция была правильной. Если это не так, то CPU все равно простаивал.

Этот же метод спекуляций может быть использован для фреймов Ethernet: начните работать как можно скорее с данными в начале кадра и только зафиксируйте эту работу после подтверждения правильности кадра.

Особо следует отметить, что, как ожидается, современный Ethernet не найдет столкновений (коммутаторы повсюду) и имеет очень низкий BER. Таким образом, заставляя все кадры иметь 1-кадровую задержку на случай, если один кадр окажется недействительным, явно расточительно, если вы занимаетесь наносекундами.

Ethernet основан на основе кадра, а не байт. Если вы хотите получить доступ к байтам, используйте последовательный протокол вместо bastardizing Ethernet.

Если доступ к данным в кадре, после чего она полностью получили «бастардизация», то мне жаль разорвать его к вам, но это продолжалось по крайней мере с 1989 года Cut-through switching. На самом деле, обратите внимание, что описанная техника действительно оставляет плохие кадры, поэтому она более чистая, чем сквозное переключение, что приводит к неудачным кадрам.

Получение прерывания за каждый бит будет ужасным. Если опрос, вам нужно будет использовать полные процессоры, предназначенные только для RX. Задержка NUMA сделает невозможным.

Все эти вопросы уже обсуждаются DPDK и аналогичными (NetMap?). Конечно, нужно тщательно настроить систему, чтобы убедиться, что вы работаете с оборудованием, а не против него. Опрос полностью исключается путем опроса. Одноядерное 3-ГГц ядро ​​достаточно далеко от RX, не снимая кадров на 10GbE. NUMA - известная проблема, но, как таковой, вам нужно только тщательно ее разбирать.

Чтобы уменьшить латентность, вы можете перейти на более высокоскоростной стандарт Ethernet.

Да, 100GbE (например) работает быстрее, чем 10GbE. Но это не поможет, если ваш провайдер работает в 10GbE и/или если ваше соревнование также переместится на 100GbE. Цель состоит в том, чтобы уменьшить латентность по данному стандарту Ethernet.

Answer 1

ОК, поэтому я нашел ответ сам. Например, SolarFlare предоставляет только такой тип потокового доступа к входящим байтам, по крайней мере внутри FPGA (некоторые?) Своих сетевых адаптеров.

Это используется, например, для разбиения длинного пакета на более мелкие пакеты, каждый из которых направляется в VNIC. Там приводится пример объясняется в этом SolarFlare presentation, at 49:50:

Пакеты прибывают от провода - имейте в виду, что все это сквозной, так что вы не знаете длину в этой точке - вы только один метаданных слова в начале.

Это также означает, что хост по-прежнему связывается с NIC традиционным способом: это просто выглядит как различные полностью сформированные пакеты прибыли внезапно (и каждый из них может быть направлен на разные ядра, и т.д.). Таким образом, сетевой стек является скорее независимой переменной.

Хороший материал.

Answer 2

Почему бы вам просто не уменьшить MTU в вашей инфраструктуре до минимально возможного уровня, так что да вместо 1500 пакетов с 1500 байтами вы получите 15-25 (в зависимости от накладных расходов на заголовок), скажем, пакеты из 100 байтов? Вы не находитесь в диапазоне одиночных ns-латентностей, но это позволяет отбросить задержки на 10-15x без специального оборудования.