JMan

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

<br /><br /><br />Не внимательно читаем статью это сума вход трафика + исход трафика ибо нам же важно пакетов в секунду. Не важно через какую сетевую (наружную или внутреннюю) вошел пакет, главное сам факт что пакет пропустили через себя (как и у любого коммутатора есть значение пакетов в секунду). Я же написал что все ядра одинаково были загружены + - 2-5%, кроме 8 последних на них не было прерываний. Вторую часть все не как не допишу, там выложу конфиги.

<br /><br /><br />А причем тут TOE к маршрутизации ? (Та и не хотят включать поддержку его в ядро по многим причинам). Вместо него продвигают LRO, которое дает практически такое же ускорение, но сам производитель пишет что надо вырубать её при маршрутизации, та и памяти в чипе маловато, абы столько сразу потоков разгрузить :). Та и сам интел говорит что надо выключать. Выдержка из readme А когда просто сервер с End user соединениями, типа веб сервера, то LRO работает проверял еще давненько.

<br /><br /><br />Ну не знаю не накладывал, но поидей есть же зависимость между пакетами в секунду и трафиком (В среднем при большом количестве абонентов). На тему тестирования. Провели синтетические тесты теперь всех платформ включая интелы разных поколений до самых топовых. Интересные результаты получили теперь могу уже все изложить в продолжении, ожидайте очень скоро будет.

А кто эту статистику по байтикам в очереди использует ? Что-то я не нашел где оно реально используется.<br /><br /><br /><br /><br />Потом она сумируется по всем очередям и выводится всего по девайсу, статистика в ifconfig <br /><br /><br /><br />Так не важно это софт роутер или аппаратный если порт в 100% забит то будет лагать там и там. Или вы о чем-то другом.<br /><br />Я про то, чтобы тестировать в реальных условиях, у меня например на 2хЕ5530 с 6х82576EB в бондинге, при более гига в обе стороны, начинало тормозить онлайн видео, а все остальное было в норме<br /><br /><br /><br />Незаню у нас на реальном тесте жалоб небыло от клиентов, больше недели работало. И елси тормозит онлайн видео то и любые тсп сесии должны бы тормозить, ибо онлайн видео поверх тсп идет. А у нас даже спид тест спокойно по аю-ах выдавал до 90 МБит :) в пике загрузки. Такчто ТСП нормально работал.

<br />Убрал я там lock, по сравнению со стоковым вариантом изменений никаких не видно.<br /><br /><br /><br />В роутере и не будет ибо влан сейчас создает вирутальные очереди ровно количетсву виртуальных очередй в реально сетевой (и при патче с номеров очереди нету перекроса по процам). А вот если это будет просто сервер с кучей соединений типа веба то могут быть колизии, так сделал для верности.

<br /><br /><br />Так не важно это софт роутер или аппаратный если порт в 100% забит то будет лагать там и там. Или вы о чем-то другом.

<br /><br /><br />Мне пару на 3.33 Ггц по 6 ядер каждый и предоставят так сказать самый топ. АМД давали самый топ 2 по 12 ядер и 2 по 8 ядер цпу, но там частоты ниже были 2,2 для 12 ядер и 2,4 для 8 ядер. Про ваята попробуем, сначал для теста посмотрим конфиги ядра что там и как, но с вланами и разными очередями уже будет лажа. По инету много где натыкался на такой-же синдром что последняя очередь не работала на отправку, а 3 была перегружена в 2 раза больше чем другие.

<br /><br /><br />Да читал, а чем vyatta отличается от моего решения по-моему тоже самое :), только вланы модифицировал ибо с ними неправильно работали очереди. По поводу тестов, не знаю как там тестировали ребята по указной ссылке ( в чем заключался этот тест). Но приоткрою тайну, на синтетических тестах (с вланом) последняя платформа амд дала спокойно 4,5 Мпс, при этом потерь не было пинг был по прежнему 0.4 мс, и консоль работала по ссх нормально в несколько сесий (там были разные мониторинг утилиты запущены). Хотя показывало что загрузка всех 16 ЦПУ были в 100%, дальше можно дорастить Мпс и свыше 5, потерь не было, но уже юзер приложения давали притормаживания. Очень хочу на следующей недели провести тестирование интел платформы на 6 ядер в одном ЦПУ. И тогда будет видна полнота картины.

<br /><br /><br />На каждую очередь по 8000 прерываний. НАТ небыло. А вот абы понимать трафик нет флов коллектор (с другого оборудования) лил суммарно 29 тыс записей в секунду, всего не суммировали сколько активных фловов было, но в районе 3 миллионов активных фловов в сети вечерами бывает спокойно, сколько в тот момент было не могу сказать не подумали снять показатели.

Еще отвлеченный вопрос а интересно ли людям модифицированный ipset таблица, которая проверяет айпи на наличие и если есть айпи, то возвращает что есть, и кроме того делает классификацию куда отправить трафик. То есть при добавление айпи в таблицу надо указывать и номер класса куда слать трафик. Пример ipset -A test_tbl 10.13.56.7 1:ab56. Может добавить удобства когда нужно в iptables быстро посмотреть открыт ли доступ для айпи и сразу промаркировать в нужный класс трафик.

<br />Нет, не будет.<br />И это не эквивалентно.<br /><br />1. Повторное залочивание тем же потоком будет моментальным.<br /><br />2. " lock .. unlock lock +++ unlock" - тут другой поток может занять ресурс пока он будет разблокирован и изменить данные.<br />Не знаю что там за код, между блокировками, но возможно что он не сможет продолжить дальше корректную работу, ибо данные на которые он полагался будут изменены.<br /><br />3. Для инкрементации счётчиков блокировка нафик не сдалась.<br />Если нет опасности что txq будет освобождён и указатели там похерятся то и блокировка там не нужна.<br />Собственно, первое: "txq->tx_dropped++;" вроде и есть без всяких блокировок.<br /><br /><br /><br />Абы txq не ушел, в принципе там есть в начале функции dev_hold а в конце dev_put. для ++ операции точно лок не нужен, только ради += операции там лок делаю (хотя надо проанализировать асм код что генерируется и посмотреть может тоже не надо. А dev_hold сделал на случае если сетевую хотят убрать а сейчас какойто ЦПУ отправляет, то когда пакет реально отправится у него ссылка на сетевую снимется и может стать равна 0 и система освободит dev, а мы потом будем txq-> использовать для статистики, и можем получить кернел паник.

<br />Хешированные фильтры помогают как раз до этих пределов, потом начинается падение скорости и абоненты его чётко чувствуют. Сама архитектура HTB не подходит для эффективного распараллеливания. А 24 ядра, так это на оба порта (16 и 8) и 275 Kpps это всего лишь одно направление на одном интерфейсе. Карты загружены неравноморено (вход/исход) и такое распределение ядер по очередям подобрано опытным путём для оптимальной загрузки. Генерация флова присутствует, как и аккаунтинг, но они "бесплатные" в связках ipset+ulog+ipcad+ipt_account.<br /><br />JMan, загружен ли на таком трафике и конфигурации модуль nf_nat и вообще хотелось бы больше технических подробностей (sysctl/lsmod/cat /proc/interrupts и т.п.).<br /><br /> <br />Хм, раньше такого не замечали, а на какой серии intel проверяли?<br /><br /><br /><br />Проверялось на последнем ксеоне правда не 6 ядерном, а те что 4 ядерные. То есть физических ядер было 8, а с НТ 16, так вот при 16 загрузка в потолок начиналась на меньшем pps. Странна но факт похоже из-за того что при роутинге кеш часто подгружается и лишнее виртуальные ЦПУ только больше вносят таких "подгрузок" Сейчас думаю сесть за 2 часть статьи, и пожалуйста, напишите что описать более подробно, абы ничего не упустил и удовлетворил ваш интерес к данной теме. Нат не был загружен, еще раз повторяю тестировался в качестве пограничного БГП маршрутизатора. В планах и пробовать в качестве НАТ такой сервер, но пока планируем как мы в рамках сети такое сможем сделать. И в НАТ нужен шейпинг, а пока в линуксе эти все дисциплины только один ЦПУ смогут использовать. Общая дисциплина на все очереди сетевой будет, соответственно при отправке упремся в общий лок, что человек уже и видел, сам раньше такое наблюдал, в прошлом, что больше 300 К пакетов никак с шейпингом не выдавить, а вот с чистым натом легко. Есть пару идей как это можно обойти но еще надо подумать потом вынесу на общее обсуждение.

<br />А сколько прерываний в секунду оно генерировало ?<br /><br /> Посмотрел я патч, вроде бы да, lock на отправке в vlan не нужен, но у вас он все равно есть, где счетчики пакетов прибавляются. Тогда смысл ? lock-lock ... unlock-unlock будет то же по времени, что lock .. unlock lock +++ unlock . Ну последний lock-unlock кусок будет меньше по времени. Правильней бы в dev_queue_xmit() (а лучше вообще в HARD_TX_LOCK) проверять, что если текущий txq->xmit_lock_owner == smp_processor_id(), то не лочить очередь - оно уже залочено (надо будет это проверить :) )<br /><br /><br /><br /><br />1. Прерываний было 8000 тыс. 2. А я так и переписал драйвер что-бы не было лока в HARD_TX_LOCK, посмотрите там флаг один взводится который и в bond используется. А меленький лок сделал лишь бы гарантировать верность подсчета статистики. Тоесть теперь нету глобального лока в HARD_TX_LOCK, а раньше получалось что если хоть один ЦПУ влез то пока не закончит все работы аж в в реальной сетевой лок держался, и все остальные ЦПУ что захотели бы отправить сидели бы ждали в холостую в HARD_TX_LOCK.

<br />Разницы не будет особой.<br /><br />Автору респект за тест. Но есть вопросы: <br />1. Размер таблицы маршрутизации какой реально был ? Т.е. с fv все понятно, а сколько маршрутов "во внутрь" ?<br />2. Размер фаервола: сколько правил в FORWARD ? Какие правила ? Есть ли ipset ?<br />3. Какой драйвер igb: стоковый из ядра или тот, что у intel на сайте лежит ? <br />4. Какие параметры в interrupt moderation ?<br />5. Как реагирует роутер на резкое изменение таблицы маршрутизации (когда 10к маршрутов, например, пропадает) ? Меняется ли латентность ?<br />6. Сколько реально было neighbor-ов у роутера (размер таблицы arp) ?<br /><br />Да, и все таки, что в ядре правилось ? И что за баг в vlan_dev_hwaccel_hard_start_xmit (можно просто в виде unified diff ) ?<br /><br /><br /><br />1. Размер таблицы 337236 маршрутов 2. FORWARD пустой это просто пограничный маршрутизатор был. 3. igb с интела ибо ядровый не понимал команду отключения хеша флов привязки к ядру, с ней дико тормозило и теряло пакеты. Хеш таблица очень маленькая, в чипе памяти мало 512 КБайт всего. 4.interrupt moderation по умолчанию с драйвера, динамический. 5. Пробовали ложить один из фуль вью, и перестроило более 100 тыс маршрутов на латентность не влияло, ибо маршрутизация в ядре, а перестройка таблицы из юзер спейса идет (команды) и всегда меньше приоритет имеет чем BH потоки ядра. Время перестроения точно не засекали но на глаз пару сек. 6. Арп таблица была в районе 194 записей и до 270 иногда подымалась. Про драйвер ВЛАН diff прицепил. Там фикс по очередям и убрал глобальный лок при отправке в в влан пакетов ибо это логическое устройство зачем он нужен (у него и дисплины то нету абы положить в очередь пакет, елси один проц уже занял отправку) пусть уже на уровне реальной сетевой это делает. vlan_dev.c.zip