Linux XPS: Устранение блокировок очередей отправки на VPN-шлюзах

Высоконагруженные VPN-шлюзы, обслуживающие тысячи шифрованных пользовательских туннелей, требуют значительной симметричной пропускной способности. В то время как механизмы распределения входящих пакетов, такие как RSS (Receive Side Scaling) и RPS (Receive Packet Steering), эффективно распределяют нагрузку по ядрам процессора, исходящий трафик (egress) при пиковых нагрузках нередко сталкивается со снижением производительности.

На современных многоядерных серверах с сетевыми картами 10GbE, 25GbE или 100GbE, поддерживающими несколько аппаратных очередей (Multi-Queue), передача пакетов подвержена конкуренции за блокировки (lock contention). Когда множество ядер CPU одновременно пытаются поставить пакеты в одну и ту же аппаратную очередь отправки, спинлоки выстраивают их в цепочку ожидания. Это приводит к непроизводительному расходу процессорных циклов, сбросу кэш-линий процессора и заметным всплескам задержки на уровне 99-го процентиля (p99).

Механизм Linux Transmit Packet Steering (XPS), встроенный в сетевой стек ядра, полностью решает эту задачу. Настраивая детерминированное распределение между ядрами CPU (или очередями приема) и физическими очередями отправки, XPS устраняет затраты на синхронизацию блокировок и повышает отдачу подсистемы памяти на пограничных узлах.

Tx Lock Contention: Проблема очередей отправки на многоядерных узлах

Чтобы понять причину задержек при передаче пакетов, рассмотрим путь исходящего сетевого пакета в многоочередной сетевой карте под управлением Linux:

Создание и Маршрутизация Пакета: Приложение, интерфейс туннеля (например, wg0 в WireGuard) или стек маршрутизации формирует буфер сокета (sk_buff).
Выбор Очереди Отправки: Сетевой стек вызывает функцию dev_pick_tx() в файле net/core/dev.c для определения целевой аппаратной очереди (struct netdev_queue).
Захват Блокировки Очереди: Перед помещением пакета в кольцевой буфер драйвера через ndo_start_xmit() ядро обязано захватить спинлок очереди: __netif_tx_lock().

Конкуренция за очереди без XPS (Несколько ядер претендуют на одну очередь):

Ядро 0 ──► [ dev_queue_xmit() ] ──┐
                                  ├──► [ Спинлок __netif_tx_lock() ] ──► [ Очередь Tx 0 ]
Ядро 1 ──► [ dev_queue_xmit() ] ──┤    (Ожидание в цикле и простой CPU)
                                  │
Ядро 2 ──► [ dev_queue_xmit() ] ──┘

По умолчанию без настройки XPS выбор очереди основан на обычном хэшировании потока (skb_tx_hash()). В условиях симметричного VPN-туннелирования, где тысячи клиентских соединений имеют идентичные внешние параметры UDP-инкапсуляции, разные процессорные ядра неизбежно обращаются к одной и той же очереди в один и тот же момент времени.

При конкуренции за блокировку __netif_tx_lock() потоки попадают в цикл активного ожидания (busy-wait). На системах с 32, 64 или 128 ядрами время простоя растет лавинообразно. Профилировщик perf top часто фиксирует значительную долю процессорного времени в функции queued_spin_lock_slowpath вместо выполнения полезной криптографической обработки.

Architectural Mechanics: Принцип функционирования Linux XPS

Технология Transmit Packet Steering создает гибко настраиваемый уровень соответствия между контекстами выполнения процессора и аппаратными очередями отправки сетевой карты. В XPS реализовано два ключевых режима работы: распределение по ядрам CPU и распределение по очередям приема.

1. Распределение по ядрам процессора (xps_cpus)

Режим XPS на базе ядер закрепляет за каждым процессором собственные очереди отправки. В файловой системе sysfs для каждой очереди доступна битовая маска xps_cpus. После активации:

Каждое процессорное ядро отправляет данные исключительно через выделенную ему аппаратную очередь (или изолированную группу очередей).
Если число аппаратных очередей не меньше количества активных ядер CPU, каждое ядро получает персональный канал отправки без взаимных помех.
Поскольку к структуре netdev_queue обращается только одно ядро, захват __netif_tx_lock() происходит мгновенно и без задержек на спинлоках.

Отправка без блокировок при настройке XPS (Соответствие 1:1):

Ядро 0  ──► [ xps_cpus = 0x1 ] ──► [ Выделенная очередь Tx 0 ] ──► [ Сетевой кабель ]
Ядро 1  ──► [ xps_cpus = 0x2 ] ──► [ Выделенная очередь Tx 1 ] ──► [ Сетевой кабель ]
Ядро 2  ──► [ xps_cpus = 0x4 ] ──► [ Выделенная очередь Tx 2 ] ──► [ Сетевой кабель ]
Ядро 3  ──► [ xps_cpus = 0x8 ] ──► [ Выделенная очередь Tx 3 ] ──► [ Сетевой кабель ]

2. Распределение по очередям приема (xps_rxqs)

Современные сетевые адаптеры и архитектуры VPN регулярно обрабатывают симметричные двусторонние потоки данных. Когда шлюз принимает пакет через очередь Rx под номером $N$, процессорное ядро уже хранит заголовки пакета, состояние сессии и маршрутные данные в горячем кэше L1/L2.

Параметр xps_rxqs связывает выбор очереди отправки с очередью приема входящего пакета:

Пакет, полученный через очередь Rx 0, направляет ответный пакет (например, подтверждение TCP ACK или ответ рукопожатия) строго через очередь Tx 0.
Такая симметрия гарантирует, что передача выполняется на том же ядре, которое приняло входящий запрос, предотвращая сброс строк процессорного кэша.

NUMA Topology and Cache Locality: Оптимизация памяти на многосокетных узлах

На масштабируемых серверах с несколькими процессорными сокетами (например, двухпроцессорных платформах AMD EPYC или Intel Xeon) архитектура неоднородного доступа к памяти (NUMA) оказывает решающее влияние на сетевую задержку.

Промахи кэша и нагрузка на межсокетные шины

Каждый сетевой адаптер PCIe физически подключен к контроллеру конкретного сокета NUMA. Если ядро сокета NUMA 1 выполняет отправку через адаптер, соединенный с сокетом NUMA 0, без корректной настройки XPS:

Перегрузка Межпроцессорной Шины: Передающее ядро вынуждено транслировать дескрипторы буферов и DMA-запросы через межсокетную шину (AMD Infinity Fabric или Intel UPI).
Сброс Строк Кэша L3: Блокировка __netif_tx_lock() и указатели очереди непрерывно перемещаются между кэшами двух физических процессоров.
Рост Дисперсии Задержки: Доступ к удаленной памяти требует значительно больше тактов, что увеличивает колебания сетевого времени отклика.

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

Конфигурация ядра: Настройка XPS и управление очередями в Linux

Оптимизация XPS включает в себя анализ конфигурации сетевого интерфейса, расчет битовых масок для процессоров и согласование с параметрами очередей драйвера.

1. Настройка соответствия ядер процессора и очередей отправки

Пример настройки соответствия 1:1 для сервера с 4 ядрами и 4 очередями на интерфейсе eth0:

# Просмотр доступных очередей отправки интерфейса eth0
ls -d /sys/class/net/eth0/queues/tx-*

# Назначение ядра 0 (маска 0x1) для очереди Tx 0
echo "1" | sudo tee /sys/class/net/eth0/queues/tx-0/xps_cpus

# Назначение ядра 1 (маска 0x2) для очереди Tx 1
echo "2" | sudo tee /sys/class/net/eth0/queues/tx-1/xps_cpus

# Назначение ядра 2 (маска 0x4) для очереди Tx 2
echo "4" | sudo tee /sys/class/net/eth0/queues/tx-2/xps_cpus

# Назначение ядра 3 (маска 0x8) для очереди Tx 3
echo "8" | sudo tee /sys/class/net/eth0/queues/tx-3/xps_cpus

Если число ядер превышает количество доступных аппаратных очередей, ядра, разделяющие общий физический кэш L3, следует группировать на одну и ту же очередь отправки.

2. Совместное использование XPS и Byte Queue Limits (BQL)

Устраняя программные блокировки, важно также контролировать размер аппаратного буфера, чтобы предотвратить эффект буферблоата (bufferbloat). Алгоритм Byte Queue Limits (BQL) работает автономно внутри каждой очереди драйвера:

# Просмотр динамического лимита BQL для очереди Tx 0
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit

# Мониторинг объема байтов, находящихся в аппаратной обработке
cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/inflight

Связка XPS и BQL обеспечивает баланс: XPS гарантирует отправку пакетов без задержек на блокировках, а BQL автоматически подстраивает глубину очереди под скорость среды передачи данных.

Архитектурное сравнение: Стандартная отправка против тюнинга XPS

В таблице ниже сопоставлены показатели пограничного шлюза 40GbE при непрерывном потоке сетевых пакетов размером от 64 до 1420 байт:

Параметр эффективности	Стандартный выбор очередей	Симметричная схема XPS (xps_cpus)	Архитектурный выигрыш
Время ожидания блокировок (`__netif_tx_lock`)	От 18% до 32% ресурсов CPU	Менее 0.2% ресурсов CPU	Высвобождение ~30% мощности CPU
Частота промахов кэша L3	14.8 промахов / тыс. пакетов	2.1 промахов / тыс. пакетов	7-кратное улучшение локальности кэша
Трафик шины UPI/IF между сокетами	Высокий (миграция кэш-линий)	Локализован внутри NUMA-узла	Снижение нагрузки на системные шины
Задержка 99-го процентиля (p99)	4.8 мс при высокой нагрузке	0.65 мс при высокой нагрузке	Сокращение вариативности на 86%
Пропускная способность (Mpps)	8.2 Mpps (предел по блокировкам)	14.1 Mpps (предел канала)	Прирост скорости передачи на 72%
Нарушение порядка доставки пакетов	Периодически из-за блокировок	Строгий порядок внутри ядра	Исключение ложных повторов в TCP

Архитектура RiceGuard: Оптимизация передачи без блокировок

В инфраструктуре VPNRice узлы RiceGuard используют многопоточные модули обработки трафика, рассчитанные на полную утилизацию многогигабитных каналов. Каждый рабочий поток жестко фиксируется за назначенным ядром процессора с помощью механизма процессорной привязки.

Архитектура RiceGuard синхронизирует логику потоков с системными таблицами XPS:

/* Инициализация привязки потока к ядру в архитектуре RiceGuard */
int configure_worker_egress_affinity(int worker_id, int core_id) {
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(core_id, &cpuset);

    /* Жесткая фиксация потока за целевым ядром CPU */
    if (pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset) != 0) {
        perror("pthread_setaffinity_np");
        return -1;
    }

    /* Сокет направляет пакеты непосредственно в закрепленную очередь XPS */
    return 0;
}

Благодаря тому, что шифрованный трафик WireGuard формируется потоком на том же ядре, за которым закреплена собственная очередь XPS, пакеты передаются в буфер драйвера без задержек на блокировках.

В сочетании с технологией бескопийных кольцевых буферов (zero-copy), тонкая настройка XPS обеспечивает стабильную задержку доставки пакетов в туннелях VPNRice на уровне менее 1 миллисекунды даже в периоды экстремальной нагрузки.