В чем основное отличие между RSS, RPS и RFS?

Вопрос: Как известно, существуют: https://www.kernel.org/doc/Documentation/networking/scaling.txt RSS: получение бокового масштабирования RPS: получение рулевого управления пакетами RFS: управление потоком приема Означает ли это, что: RSS - позволяет использовать много процессорных ядер для обработки Soft-irq из Ethernet (один процессорный ядро для каждой очереди Ethernet) RPS - позволяет обрабатывать Soft-irq для всех пакетов из одного и того же соединения

Вопрос:

Как известно, существуют: https://www.kernel.org/doc/Documentation/networking/scaling.txt

  • RSS: получение бокового масштабирования
  • RPS: получение рулевого управления пакетами
  • RFS: управление потоком приема

Означает ли это, что:

  • RSS – позволяет использовать много процессорных ядер для обработки Soft-irq из Ethernet (один процессорный ядро для каждой очереди Ethernet)
  • RPS – позволяет обрабатывать Soft-irq для всех пакетов из одного и того же соединения на одном и том же CPU-Core
  • RFS – позволяет нам обрабатывать Soft-irq для всех пакетов из одного и того же соединения на одном и том же CPU-Core, на котором поток нашего приложения выполняет это соединение

Это верно?

Лучший ответ:

Цитаты: https://www.kernel.org/doc/Documentation/networking/scaling.txt.

  • RSS: Receive Side Scaling – реализовано аппаратное обеспечение и хеширует некоторые байты пакетов (“хэш-функция по сети и/или транспортному уровню headers–, например, хэш 4-х кортежей по IP-адресам и TCP-портам пакета”). Реализации различны, некоторые могут не фильтровать наиболее полезные байты или могут быть ограничены другими способами. Это распределение фильтрации и очереди выполняется быстро (требуется только несколько дополнительных циклов в hw для классификации пакета), но не переносится между некоторыми сетевыми картами или не может использоваться с туннелированными пакетами или некоторыми редкими протоколами. И иногда ваше оборудование не поддерживает количество очередей, достаточное для того, чтобы получить одну очередь для каждого ядра ядра.

RSS должен быть включен, когда задержка является проблемой или всякий раз, когда обработка прерываний является узким местом. Распространение нагрузки между процессорами уменьшает длину очереди.

  • Receive Packet Steering (RPS) “является логически программной реализацией RSS. Будучи в программном обеспечении, он обязательно называется позже в датапате”. Таким образом, это программная альтернатива аппаратным RSS (по-прежнему анализирует некоторые байты для хэширования их в id очереди), когда вы используете аппаратное обеспечение без RSS или хотите классифицировать на основе более сложного правила, чем hw, или может иметь протокол, который не может быть проанализирован в HW RSS-классификатор. Но с RPS больше ресурсов процессора используются, и есть дополнительный межцентровый трафик.

RPS имеет некоторые преимущества перед RSS: 1) его можно использовать с любым сетевым адаптером, 2) программные фильтры могут быть легко добавлены в хэш по новым протоколам, 3) он не увеличивает скорость прерывания аппаратного устройства (хотя он вводит межпроцессорные прерывания (АПИ)).

  • RFS: Управление потоком приема подобно RSS (программный механизм с большим количеством накладных расходов на процессор), но это не просто хеширование в псевдослучайную идентификатор очереди, но “учитывает местность приложений”. (таким образом, обработка пакетов, вероятно, будет быстрее из-за хорошей локальности). Очереди отслеживаются, чтобы быть более локальными для потока, который будет обрабатывать полученные данные, а пакеты доставляются для правильного ядра ЦП.

Цель RFS заключается в повышении производительности передачи данных путем управления обработкой пакетов ядра процессором, где работает поток приложений, потребляющий пакет. RFS полагается на те же механизмы RPS, чтобы вставлять пакеты в отставание другого CPU и пробуждать этот CPU…. В RFS пакеты не пересылаются напрямую по значению их хеша, но хеш используется как индекс в таблицу поиска потока. Эта таблица отображает потоки в CPU, где эти потоки обрабатываются.

  • Ускоренный RFS – RFS с поддержкой hw. (Проверьте сетевой драйвер для ndo_rx_flow_steer) “Ускоренный RFS – это RFS, что RSS для RPS: механизм ускорения нагрузки с аппаратным ускорением, который использует мягкое состояние для управления потоками на основе того, где работает поток приложений, потребляющий пакеты каждого потока”.,

Аналогичный метод для передачи пакетов (но пакет уже сгенерирован и готов к отправке, просто выберите лучшую очередь для его отправки – и упростите пост-обработку, например, освобождение skb)

  • XPS: управление передачей пакетов: “записывается сопоставление от CPU к очереди оборудования. Цель этого сопоставления обычно заключается в том, чтобы назначать очереди исключительно подмножеству процессоров, где завершение передачи для этих очередей обрабатывается на процессоре в пределах этот набор “

Ответ №1

Ответ osgx охватывает основные различия, но важно отметить, что также можно использовать RSS и RPS в унисон.

RSS контролирует выбранную очередь HW для приема потока пакетов. После выполнения определенных условий прерывание будет выдано SW. Обработчик прерываний, который определяется драйвером NIC, будет отправной точкой SW для обработки принятых пакетов. Код, который будет опросить пакеты из соответствующей очереди приема, может выполнить начальную обработку, а затем переместить пакеты для обработки протокола более высокого уровня.

В этом случае механизм RPS может быть использован, если он настроен. Драйвер вызывает netif_receive_skb(), который (в конечном итоге) проверяет конфигурацию RPS. Если существует, то он будет вставлять SKB для продолжения обработки выбранного CPU:

int netif_receive_skb(struct sk_buff *skb) { … return netif_receive_skb_internal(skb); } static int netif_receive_skb_internal(struct sk_buff *skb) { … int cpu = get_rps_cpu(skb->dev, skb, &rflow); if (cpu >= 0) { ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail); rcu_read_unlock(); return ret; } … }

В некоторых сценариях было бы разумно использовать RSS и RPS вместе, чтобы избежать узких мест использования процессора на принимающей стороне. Хорошим примером является IPoIB (IP over Infiniband). Не вдаваясь в слишком много деталей, IPoIB имеет режим, который может открыть только один канал. Это означает, что весь входящий трафик будет обрабатываться одним ядром. Правильно настроив RPS, часть загрузочной нагрузки может использоваться несколькими ядрами, что значительно повышает производительность для этого сценария.

Поскольку была упомянута передача, стоит отметить, что передача пакетов, которая возникает в результате процесса приема (ACK, пересылка), будет обрабатываться из того же ядра, выбранного netif_receive_skb().

Надеюсь это поможет.

Оцените статью
Добавить комментарий