Практикум по серверным сетям
Сетевой приём в Linux: RSS, RPS и привязка IRQ
Курс учит разбирать путь входящего трафика от аппаратной очереди сетевой карты до CPU: отличать RSS от RPS, находить IRQ очередей и проверять привязку прерываний.
Что вы сможете сделать
- Отличать аппаратное распределение RSS от программного RPS.
- Находить IRQ сетевых очередей и читать их привязку к CPU.
- Составлять короткий протокол приёмки сетевого тракта без обещаний производительности по одной настройке.
1. Разберите аппаратные очереди RSS
RSS начинается на сетевой карте: поток попадает в аппаратную очередь, а очередь связана со своим прерыванием.
RSS распределяет потоки по нескольким аппаратным очередям приёма; разные очереди могут обрабатываться разными CPU.
Для каждой очереди приёма документация Linux описывает отдельное IRQ; при MSI-X прерывания можно направлять на разные CPU.
Соответствие сетевых очередей и IRQ проверяют по /proc/interrupts, а не по рекламному числу очередей карты.
Распределение приёмных IRQ между CPU — рекомендация для случая, когда обработка прерываний становится узким местом; это не обещание ускорения любой нагрузки.
Работающий irqbalance может позже изменить ручные назначения IRQ.
2. Отделите RPS от RSS
RPS работает позже аппаратного приёма: Linux выбирает CPU для дальнейшей обработки пакета программно.
RSS выбирает аппаратную очередь раньше в тракте, а RPS выбирает CPU для последующей обработки пакета уже в Linux.
RPS не требует специального механизма в сетевой карте: документация Linux допускает его использование с любой NIC при наличии CONFIG_RPS.
Для каждой очереди список CPU RPS задаётся bitmap в /sys/class/net/ИМЯ/queues/rx-N/rps_cpus.
Нулевой rps_cpus выключает RPS для очереди; тогда пакет остаётся на CPU, обслужившем прерывание.
Если RSS уже даёт отдельную аппаратную очередь каждому CPU, документация называет RPS вероятно избыточным; при меньшем числе очередей он может быть полезен.
3. Проверьте привязку IRQ
После того как IRQ очередей найдены, проверьте, какие CPU действительно разрешены для каждого прерывания.
smp_affinity задаёт CPU битовой маской, а smp_affinity_list — списком CPU для того же IRQ.
Нельзя исключить из affinity все CPU; если контроллер не поддерживает изменение affinity, значение останется исходным.
default_smp_affinity задаёт исходную маску для ещё не активированных IRQ, после чего конкретный IRQ может иметь свою настройку.
Если работает irqbalance, повторно проверьте affinity после настройки: служба может изменить назначение IRQ.
4. Соберите протокол приёмки
RSS, RPS и affinity отвечают на разные вопросы. В протоколе их нужно хранить отдельно, иначе легко принять настройку за доказательство производительности.
Сначала сохраните аппаратную часть: число очередей RSS, их IRQ и текущие CPU этих IRQ.
Затем сохраните программную часть: rps_cpus для каждой очереди и факт, включён ли RPS.
Отдельно зафиксируйте smp_affinity_list и наличие irqbalance, чтобы понимать, кто управляет IRQ.
После изменения сравните сетевую производительность, задержку и загрузку CPU; сами настройки не доказывают полезный эффект.
Проверьте инженерное мышление
Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.
Следующий шаг
Сформулируйте задачу и уточните требования к своей системе.
Подготовить подбор с ДелектусомОткроется черновик вопроса. Отправьте его, когда будете готовы.
Источники курса
Ссылки приведены один раз для всего курса, чтобы не мешать чтению каждого тезиса.
- Официальная документация
Scaling in the Linux Networking Stack
Linux Kernel · Linux kernel documentation; страница проверена 19 сентября 2026 года
RSS, RPS, RFS и XPS; для этой партии использованы разделы RSS/RPS и замечание об irqbalance.
Открыть первоисточник - Официальная документация
SMP IRQ affinity
Linux Kernel · Linux kernel documentation; страница проверена 19 сентября 2026 года
Интерфейсы /proc/irq/*/smp_affinity и smp_affinity_list, их смысл и ограничения.
Открыть первоисточник