RPS Linux: перенос обработки на другой CPU имеет собственную цену
Фотография конкретного исполнения не приложена.
RPS может распределять приёмную работу даже без богатых аппаратных возможностей NIC. При этом он действует позже RSS в datapath. Нельзя считать включение RPS физическим добавлением новых RX queues или автоматическим переносом самого hardware interrupt.
Документация описывает помещение пакета в backlog выбранного CPU и пробуждение обработки. Такой механизм создаёт межпроцессорные взаимодействия, включая IPI. Он способен уменьшить перегрузку одного обработчика, но увеличить стоимость передачи данных между CPU и cache domains.
При достаточном аппаратном RSS дополнительное steering может не принести выгоды. Важны расположение interrupts, число потоков и NUMA. Простое назначение всех CPU в bitmap не подтверждает лучший результат; оно расширяет возможные маршруты обработки и расход ресурсов.
В приёмке сравнивают согласованные варианты на одинаковой нагрузке. Измеряют drops, загрузку, IPI и прикладные задержки, сохраняя остальные параметры. Выбор оценивают по узкому месту конкретного хоста. Более ровные столбцы CPU сами по себе не доказывают меньшую стоимость обработки или более предсказуемое время ответа.
Основание — Official versioned Linux network documentation displaying6.18.0, networking/bonding, scaling and bridge, разделы RPS: Receive Packet Steering; suggested CPU selection. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — официальная версия документации Linux с заголовком 6.18.0. Это фиксированная редакция, а не утверждение об установленном или последнем ядре. Реальные NIC, драйвер, switch и параметры хоста не проверялись; настройки и сетевые испытания не выполнялись.
