Распределите IP-пакеты по разным очередям NIC с помощью MSI (сообщение сигнализирует о прерываниях)
Сетевая карта Gigabit Ethernet NetXtreme II BCM5709 поддерживает функцию MSI (прерывания по сигналу сообщений) и имеет 8 очередей. Каждая очередь имеет свой собственный обработчик прерываний в /proc/interrupts. То, что я пытаюсь сделать, это сказать NIC, какие пакеты должны идти в какую очередь.
Вопросы:
- Можно ли вручную указать, какие IP-пакеты должны поступать в какую очередь по инкапсулированному типу протокола (например, пакеты IPsec отправляются в одну очередь, а TCP-пакеты - в другую очередь)?
- Если это возможно - как я могу сделать это под Linux?
- Если это невозможно - стоит ли смотреть на сетевые карты с поддержкой MSI-X, чтобы решить эту проблему?
Больше деталей:
У нас есть один интерфейс, который завершает IPSec и перенаправляет / завершает TCP-соединения. Расшифровка пакета IPSec является встроенной (это означает, что дешифрование выполняется в том же контексте ksoftirqd/X). Мы пытаемся выяснить, сможем ли мы улучшить общую производительность, если пакеты IPSec будут запланированы на другом процессоре, а не на пакетах TCP. Еще одно ограничение заключается в том, что код IPSec не является MP-безопасным, поэтому я не могу запустить его под более чем одним ksoftirqd/X. По умолчанию кажется, что пакеты распределены / хэшированы исходным IP через 8 очередей NIC. Узким местом является IPSec, который блокирует трафик TCP во время дешифрования / шифрования пакетов IPSec на ~100% ЦП в контексте ksoftirqd/X.
Операционная система - Ubuntu 10.10 (2.6.32-27-сервер), а NIC - Broadcom BCM5709.
1 ответ
Если кто-то еще будет пытаться выяснить, как заставить Linux Networking TCP/IP стек масштабироваться на нескольких ядрах процессора...
MSI может использоваться двумя базовыми технологиями NIC для распределения пакетов по нескольким очередям. Каждая очередь сетевого адаптера обрабатывается отдельным прерыванием на выделенном ядре ЦП для достижения масштабируемости:
- RSS (масштабирование на стороне приема) - распределяет пакеты по разным очередям по исходному и целевому IP и, если применимо, по исходному и целевому портам TCP/UDP.
- VMDq (очереди устройства виртуальной машины) - распределяет пакеты по MAC-адресу или тегам VLAN. В основном используется гипервизорами ВМ, но я не вижу причин, по которым его нельзя было использовать в установках, отличных от ВМ.
Проблема с RSS в том, что он всегда использует исходный IP для генерации хеша. Хеш используется для определения того, в какую очередь должен идти этот пакет. Это означает, что нельзя контролировать, какие пакеты должны идти в какую очередь, если он также не контролирует IP-адреса источника.
VMDq кажется более подходящим для моей проблемы, потому что он распределяет пакеты по MAC-адресу назначения. Это может быть так же просто, как присвоение двух разных IP-адресов одному и тому же интерфейсу.
Источник: