Равномерное распределение пропускной способности между интерфейсами

Какая железяка, какая там ОС?

Обычно принято различать производительность в Мегабитах и в пакетах в секунду и пакеты 64 байта это скорее pps.

Какую именно скорость вы измерили? Может у вас исходно разный поток с аплинков на железяку шёл.

А bonding пробовал?

Железяку не имею права говорить. Коммерческая поделка.
Ядро Linux 4.1

Трафик генерировался на тестовом стенде Ixia, соответсвтенно, трафик однотипный и тут всё ок. Чтобы не быть голословным - пускали тот же трафик на один из маршрутизаторов, который оказался под рукой, там распределение оказалось равномерным. Про скорости не скажу, не записывал уже.

Агрегация двух интерфейсов в один? Если это имелось ввиду, то мне это не подходит.

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

а сейчас она делится по принципу - кто первым отхватил канал

ты же понимаешь, что если через TCP сокет шлются данные, то пакеты не могут поочерёдно идти то через один, то через другой интерфейс?

я где-то говорил про TCP?

Я первый спросил

Никто не подразумевал, что пакет должен сначала идти то через один, то через другой интерфейс. И я написал, что интерфейсы находятся в разных подсетях и трафик в них не пересекается. Соответственно, ядро просто должно обоим потокам данных выдать одинаковый приоритет и отбалансировать пропускную способность (в pps, я так понимаю) каким-либо из доступных способов, например, на одном из каналов искуственно отодвигая/отбрасывая пакеты в случае необходимости.

Я не специалист по сетям, конечно, но учитывая, что один из производителей маршрутизаторов в своих прошивках на Linux смог такое реализовать, то берусь предположить, что это можно воспроизвести и на других железках.

Не очень понятен профиль вашего трафика и почему нельзя использовать аггрегацию линков.
Если профиль позволяет, то надо смотреть в сторону балансировки на уровне маршрутизации.
Если нет - то только аггрегация линков с каким-нибудь LACP

Интерфейсы должны остаться независимыми. Т.к. они будут находиться в разных подсетях и выполнять роль пограничного маршрутизатора дял офиса (сейчас там только 3 аплинк-интерфейса, а будет 8 ланов, 3 аплинка для подлючения к операторам и прочих нужд + wi-fi карточка). Вот теперь представьте,что будет, если без настройки QoS появится в сети клиент, который займёт всю пропускную способность железа (все каналы гигабитные).

Т.е. мне хотелось бы добиться более-менее справедливой балансировки всего трафика проходящего через ядро даже без полноценной настройки QoS. FQ_CoDel это должен делать, но как я понял он балансирует только трафик на интерфейсе, а не весь, как мне надо.

Если я правильно понял, то у ТС вобще нет задачи агрегации.

Он каким-то образом загружает трафиком два интерфейса, на пределе возможносей железа, и хочет получить одинаковые числа.

Почти.

Про «каким-то образом» еще раз поясню - тестовый стенд Ixia, 2 маршрута UDP трафика. Это, как показывается практика, достаточное условие чтобы выжать все соки из железок без аппаратного ускорения маршрутизации.

Про «получить одинаковые числа» - не совсем, я хочу чтобы в синтетических условиях одинаковый вид трафика балансировался на два одинаковых интерфейса приблизительно равномерно. А не в соотношении 1/5 как это сейчас есть.

Давайте схему сети смотреть, а то это как-то всё слишком запутывается

Если я правильно понял, то у ТС вобще нет задачи агрегации

Ну тут это же больше как очевидный инструмент, а не как цель или как задача

Железка просто форвардит IP пакеты с одного интерфейса на второй, и со второго на первый. Про скорости непонятно. По идее есть pps форвардинга с первого на второй, есть pps форвардинга со второго на первый, есть суммарный pps. Pps форвардинга с первого на второй надо смотреть по счетчикам output packets на втором интерфейсе, pps форвардинга со второго на первый надо смотреть по счетчикам output packets на первом интерфейсе.

Если генератор UDP трафика генерирует одинаковые потоки дейтаграмм в обоих направлениях, а pps форвардинга разные, значит железка перегружена, и дропает пакеты. Почему дропает больше пакетов, входящих через один интерфейс, чем входящих через второй? Наверное аппаратно интерфейсы разные, с разной величиной буфера, с разными возможностями и/или скоростями передачи пакетов из буфера в оперативку хоста.

Так всё и есть. pps на форвардинге разные, т.к. железка работает на пределе. Про «интерфейсы разные, с разной величиной буфера» и все такое отпадает, т.к. большую пропускную способность на форвардинге показывает тот интерфейс, на который первым начали генерировать трафик. Т.е., повторюсь, какой интерфейс первым занял пропускную способность канала, тот и держит её.

Схема сети тут не причем, пример и задача чисто синтетические. Всё это делалось для определения максимальной пропускной способности железа в некоторых условиях и выявления огрехов в распределении нагрузки.

Мне надо просто настроить систему так, чтобы планировщик равномерно распределял пропускную способность по всем интерфейсам. Я уже не знаю как еще можно обьяснить.

Вы вобще уверены, что у вас дело до планировщика доходит? Может у вас возникает приоритет в обработке прерываний одной из сетёвок, а вторая начинает дропать пакеты, то есть они как-бы вобще в маршрутизацию не попадают.

Попробуйте зажать максимальную входную полосу интерфейса через tc ingress policer, может полегчает.

Может остановить службу irqbalance и попытаться вручную раскидать прерывания по процессорам? Смотри http://habrahabr.ru/post/108240/

Это SoC, там сетевых карт нет, всё встроено... только PHY на шину посажен и всё. Потому думаю вряд ли тут дело в приоритете прерываний, но поиграться с ingress policer, всё же, попробую. Спасибо.

Спасибо за наводку, сейчас попробуем.

Не помогло. Прерывания распределены ровно, но баланса по трафику по прежнему нету.

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

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

Потому вопрос о корректности формируемых пакетов, методики тестирования (за основу брался RFC2544) и схемы подключения можно считать исчерпанным и более не поднимать.
Проблема либо в ПО установленном на устройстве, либо в самом железе. Если ПО, то можно исправить, если железо, то печаль-беда.

И я написал, что интерфейсы находятся в разных подсетях и трафик в них не пересекается.

Соответственно, ядро просто должно обоим потокам данных выдать одинаковый приоритет и отбалансировать пропускную способность

Я не специалист по сетям

Хотел было спросить, как видится механизм такой невероятной балансировки, и, вдруг...

один из производителей маршрутизаторов в своих прошивках на Linux смог такое реализовать,

Кто, и что именно сделал ?

Вот теперь представьте,что будет, если без настройки QoS появится в сети клиент, который займёт всю пропускную способность железа (все каналы гигабитные).

Или имеется ввиду балансировка мощности CPU для обработки трафика на всех интерфейсах ?

Например, приносили на тесты коммерческий образец маршрутизатора ZTE, он выдавал стабильные показатели PPS поровну разделенные на все интерфейсы: на ZTE задействовали 4 интерфейса, производительность получилась (цифра с потолка, точных данных не помню) в пределах 200k pps, на каждом интерфейсе высчитали приблизительно по 50k pps. И это без настройки QoS, только маршрутизация. То же самое для 2,3,5 интерфейсов. Само-собой, с увеличением количества задействованных интерфейсов и настроенных маршрутов общая производительность падала, но распределение pps на интерфейсы сохранялась.

Да, такая формулировка корректнее будет) я же говорю, что не спец в этом.

Да, такая формулировка корректнее будет) я же говорю, что не спец в этом.

Тогда в голову только вариант с обработкой прерываний приходит, как уже успели написать. В любом случае, копать больше некуда. А «распределены ровно» - там несколько ядер ? А по скольку очередей у сетевых интерфейсов ? Там /proc/interrupts есть ?

Настройка QoS к этому отношения вообще никакого не имеет, это другой уровень балансировки совсем. Разве что отъедает мощность CPU дополнительно, и только.

А «распределены ровно» - там несколько ядер ? А по скольку очередей у сетевых интерфейсов ? Там /proc/interrupts есть ?

Да, там 4 ядра. Как я понял по 1 очереди на интерфейс. Да, само-собой. Ядро Linux 4.1 с патчами для поддержки данного SoC и сопутствующего железа.

Да, само-собой.

А что там ? cat /proc/interrupts что показывает ?

Примерно так:

116:   0    0    0  550   OpenPIC   116 Level     Queue-manager portal 3
117:   0    0    0    0   OpenPIC   117 Level     Buffer-manager portal 3
118:   0    0  550    0   OpenPIC   118 Level     Queue-manager portal 2
119:   0    0    0    0   OpenPIC   119 Level     Buffer-manager portal 2
120:   0  556    0    0   OpenPIC   120 Level     Queue-manager portal 1
121:   0    0    0    0   OpenPIC   121 Level     Buffer-manager portal 1
122: 548    0    0    0   OpenPIC   122 Level     Queue-manager portal 0
123:   0    0    0    0   OpenPIC   123 Level     Buffer-manager portal 0

portal 0-3, как я понимаю, сетевые карты ? Так, а что-то ещё есть, что грузит ядра при прохождении трафика, и грузит какие ? И ради эксперимента, если все portal навесить на одно ядро, что будет ? Производительность должна просесть, но вот одинаковость не появится ли ?

portal 0-3, как я понимаю, сетевые карты ?

Почти. Там интегрировано всё в SoC. 5 или 6 гигабитных каналов раскиданы вот так вот на 4 портала.

Так, а что-то ещё есть, что грузит ядра при прохождении трафика, и грузит какие ?

Больше ничего не грузит именно при прохождении трафика. Статично всё.

И ради эксперимента, если все portal навесить на одно ядро, что будет ? Производительность должна просесть, но вот одинаковость не появится ли ?

Производительность просела в 3-3.5 раза примерно. Потоки так же дерьмово распределены по интерфейсам, даже хуже =)

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

Весь тред не читал.

Единственный способ шейпить трафик идущий в разные подсети через разные интерфейсы - это загнать его в промежуточный интерфейс типа ifb (средствами iproute2/tc на входе) или типа imq (средствами iptables на входе и/или выходе)

Весь тред не читал.

А надо. Для меня понятно стало к концу только, что ТС хочет.

Единственный способ шейпить трафик идущий

Ему не трафик шейпить надо, а распределить процессорное время поровну. Другими словами, нужно обеспечить равномерный PPS по интерфейсам.

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

Может быть. А вендору написать ? Кстати, ещё можно попробовать перетасовать прерывания/ядра, чтобы понять, проблема к ядру привязана, или к интерфейсу. Для полноты картины. Ещё можно стенд аналогичный на PC сделать, чтобы исключить ядро, либо наоборот.

Ведору писать бесполезно. А всё остальное проверю в рабочий день, спасибо)