LINUX.ORG.RU
решено Форум — Admin  

CentOS 7, бондинг, VLAN'ы и skb_warn_bad_offload

 , , , ,


0

1

Собираю для себя статистику, чтобы понять, кто виноват.

Есть кто с серверами, в которых двухголовые интеловые карты (10G) работают с драйвером ixgbe так, чтобы был сконфигурирован бондинг (802.3ad) и VLAN'ы поверх бондинга? Дистр — центось 7.1 с последними апдейтами.

Интересует, сталкивались ли с дропами пакетов (на хосте или в виртуалках, которые подключены через virtio бриджами к vlan-интерфейсам), когда в dmesg выплёвывается куча варнингов с skb_warn_bad_offload наверху стека?

Примерные багрепорты:

Предположительные фиксы:

Что интересно, этих фиксов в ядре центоси нет, поэтому буду проверять их отдельно (или центосевое ядро пересоберу, или 4.x с elrepo накачу). В убунте, похоже, их смержили, а о баге забыли.

Как воркэраунд предлагают сделать ETHTOOL_OPTS="-K enp4s0f0 sg off lro off rx off" с просадкой производительности в 4 раза.

Короче, кто сталкивался и как решал?

★★★★★

Последнее исправление: post-factum (всего исправлений: 2)

или 4.x с elrepo накачу

В ядре с elrepo какой-то странный конфиг. У меня во времена 3.14 с ним 10G-интерфейсы очень сильно грузили процессор и в результате даже близко не выдавали желаемые 10Gbit/s. Если поставить ядро от федоры или пересобрать пакет из elrepo с коняигом ядра от федоры - всё начинало работать нормально.

С описанной проблемой не сталкивался, просто предупреждаю насчёт elrepo kernel. Сетёвки у меня emulex, а не intel. Бондинг с VLAN'ами используется «наизнанку»: сначала поверх физических интерфесов VLAN'ы, а уже они попарно объёдинены в боднинг =).

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

В ядре с elrepo какой-то странный конфиг.

diff не смотрел?

Сетёвки у меня emulex, а не intel.

Похоже, что интел тут, на самом деле, и ни при чём, т.к. в репортах фигурируют даже броадкомовые карты.

Бондинг с VLAN'ами используется «наизнанку»

Почему так?

post-factum ★★★★★
() автор топика
Последнее исправление: post-factum (всего исправлений: 1)
Ответ на: комментарий от post-factum

Почему так?

У меня две разные сети (два VLAN'а) и два 10G-свитча. Хочется, чтобы трафик в разных сетях всегда шёл через разные свитчи. Но при этом так же получить защиту от выхода одного из свитчей из строя.

Deleted
()
Ответ на: комментарий от Deleted

Понял. У меня один свитч, поэтому наоборот и сконфигурено.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от dvrts

В убунте ядро версионно новее (3.16 на тот момент), и туда попали указанные мною патчи с апстрима. А в ядро центоси (3.10) их не бекпортировали.

post-factum ★★★★★
() автор топика
Ответ на: комментарий от post-factum

А на практике?

Как я понял, основная фича - вынос управления и мониторинга в юзерспейс. С возможностью писать собственные плагины.

Но для моего случая teaming не работает. Или я просто не смог его завести =).

Deleted
()
Последнее исправление: Deleted (всего исправлений: 1)

Разобрался.

Оказывается, warning возникал при форвардинге пакетов в виртуалке, а README ixgbe пишет:

WARNING: The ixgbe driver compiles by default with the LRO (Large Receive Offload) feature enabled. This option offers the lowest CPU utilization for receives, but is completely incompatible with *routing/ip forwarding* and *bridging*. If enabling ip forwarding or bridging is a requirement, it is necessary to disable LRO using compile time options as noted in the LRO section later in this document. The result of not disabling LRO when combined with ip forwarding or bridging can be low throughput or even a kernel panic.

Выключил LRO на обоих slave'ах бондинга — попустило.

post-factum ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin