s.lobanov Опубликовано 25 апреля, 2014 · Жалоба судя по симтоман у вас относительно старое ядро, не умеющее нормально работать с большим кол-вом интерфейсов. я на аналогичном xeon поднимал под 10к клиентских сессий обычным pppd на ядре 3.11. больше не пробовал ибо уперся в ram(там было совсем мало, что-то около 6-10Гб) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 25 апреля, 2014 · Жалоба Да, у меня 3.2.23, но токое же ядро у PPPoE сервера и ему нормально. Рекомендуете проапдейтится? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 25 апреля, 2014 · Жалоба на клиенте - обязательно, на сервере тоже, иначе медленно будет. http://forum.nag.ru/forum/index.php?showtopic=76343 дальше вы будете упираться в RAM Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 28 апреля, 2014 · Жалоба Спасибо за линк. Рамы у меня 16 Гб должно хватить на 15-16К сессий. Для моего теста - этого достаточно. Попробую другие ядра. О результате отпишусь, может быть ядерный клиент и не нужен будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 1 мая, 2014 · Жалоба Поменял ядро на генераторе ( 3.12.х ). Ситуация стала примерно в миллиард раз лучше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 мая, 2014 · Жалоба Dark_Angel Надеюсь, что Вы опубликуете результаты. Мне тоже интересно ибо щас нет под рукой свободных high-end серверов :( только всякий хлам и виртуалки Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 1 мая, 2014 (изменено) · Жалоба Ну а чего же с добрыми людьми не поделится? Но с очередями по прежнему шляпа. Сделал macvlan на генераторе пакетов, назначил ИПшнички, то есть src_ip другой и маки другие. Всеравно всё сливается в одну очередь на роутере. То что пакеты идут с разных маков видно на интерфейсе роутера. Это iperf. Пинг по прежнему отжирает слишком много ресурсов, но пакеты по очередям размзывает даже без всяких macvlan. Пока не понятно что делать. Изменено 1 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 мая, 2014 · Жалоба Т.е. у вас ICMPoIPoPPPoE размызываются по очередям, а UDP/TCPoIPoPPPoE нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 1 мая, 2014 (изменено) · Жалоба Да, но тут нужно понимать еще, что пинг генерит разные пакеты внутри, а iperf скорее всего одинаковые. Ну и Flow Directory пофигу что внутри фрейма PPPoE - он берет заголовки только внешнего пакета. Соответственно в этой ситуации еще более не понятно почему ICMP нормальный, а UDP - нет. Щас попробую еще TCP, но там потоком сложнее управлять. UPD. У TCP тоже самое. Изменено 1 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 мая, 2014 · Жалоба у вас карточка поддерживает явное указние метода классификации по вх. очередям? (ethtool -n/-N, http://downloadmirror.intel.com/22919/eng/README.txt ) Ну и Flow Directory пофигу что внутри фрейма PPPoE - он берет заголовки только внешнего пакета. может оно не проверяет, что между eth и ip вставлен ppp-заголовок, а просто отсчитывает номера байтов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 1 мая, 2014 · Жалоба у вас карточка поддерживает явное указние метода классификации по вх. очередям? (ethtool -n/-N, http://downloadmirro.../eng/README.txt ) Умеет, включил, но ничего не дало. Потому что UDP ( а у нас же PPPoE фреймы ). Другие опции хеширования и вообще TCP фрагментацию не умеет, судя по доке. может оно не проверяет, что между eth и ip вставлен ppp-заголовок, а просто отсчитывает номера байтов Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 мая, 2014 · Жалоба А явное задание mac->queue поддерживается у вас? flow-type ether src MAC m MAC_MASK action QUEUE_NUM Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма. tcp заголовок большой, поэтому можно пропатчить iperf, чтоб он вначало рандом/время/прочее засовывал, а запускать его в udp-режиме Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 2 мая, 2014 (изменено) · Жалоба А явное задание mac->queue поддерживается у вас? flow-type ether src MAC m MAC_MASK action QUEUE_NUM Да, поддерживается и это следующий инструмент, который я хочу попробовать после того как разберусь, почему дофолт не работает. Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма. tcp заголовок большой, поэтому можно пропатчить iperf, чтоб он вначало рандом/время/прочее засовывал, а запускать его в udp-режиме Вариант, но может оказаться, что проще будет собрать скрипт на pktgen, нежели патчить iperf. Вообще iperf меня удивил своей негибкостью. До этих экспериментов я думал, что если мне что-то надо будет поменять по скорости, то: вот он инструмент мечты, а по факту оказалось, что максимум что там можно крутить - это порт/хост у клиент/сервер, размер пакета и скорость. Чего для "глубокой аналитики" недостаточно, очевидно. Про user-space умолчим. Я вот не уверен, что смогу нагенерить 1Mpps, ибо 500Kpps, уже дает 70% нагрузки на генераторе. Изменено 2 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 2 мая, 2014 (изменено) · Жалоба Почитал доку, мейл листы и это просто грусть какая-то. Карта может много, но драйвера за ней не успевают ( а иногда просто кривые ). В итоге я не один с такой проблемой. Как строиться хеш RSS рассказано красиво и с картинками в DS, вот только на практике пакеты в начале ( до 80-го байта ) отличаются, пусть и не на много. А RSS хеш получается у них одинаковый? Но судя по диаграмме распределения пакетов, во-первых очередь может определить ether type, во-вторых туннелированные пакеты у flow director`a в матчинге не учавствуют. Но на всём этом фоне тогда не понятно как удается всё размазать пингу. Ведь туннелирование, хеш RSS и пр. - всё на месте. По маку по очередям распихивать нельзя, умеет только L4. И то очень ограниченый. Буду пробовать с ВЛАНами, т.к. тег - единственный доступный для распихивания по очередям инструмент, который по идее должен работать. UPD. ВЛАНЫ не помогают. Пакеты тупо не попадают к Flow director. Видимо мне прямой путь в mails list. UPD2. Если генерить TCP, то всё размазывается без Flow director по хешу RSS. Попробую что-то сделать через TCP. Изменено 2 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 2 мая, 2014 · Жалоба Ну с tcp, вы, вероятно, всё равно в userspace упрётесь. Поскольку проблему с поднятием сессий решили, то теперь использовать pktgen для генерации трафика очень легко Берёте псевдофайл /proc/net/pppoe: # cat /proc/net/pppoe Id Address Device 00008E07 00:11:22:33:44:55 eth0.33 Здесь 8e07 это ppp session-id(в обратном порядке, прямой порядок байт будет 0x078e (!)), 00:11:22:33:44:55 это мак-адрес браса(хотя вы и так его знаете), eth0.33 - устройство поверх которого поднята сессия. Собственно всё, вам больше ничего не надо, чтоб самостоятельно сформировать pppoe-фрейм. Единственно что неудобно, что в этом файле нет явной привязки к номеру тунеля(pppX), но в вашей задаче оно и не требуется А чтоб на сервере трафик размызывался по CPU, просто загоняете ICMPoIPv4 в payload, чтоб не эмулировать tcp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 2 мая, 2014 (изменено) · Жалоба Ну с tcp, вы, вероятно, всё равно в userspace упрётесь. Поскольку проблему с поднятием сессий решили, то теперь использовать pktgen для генерации трафика очень легко Ну в итоге так и получается. Нагенерить какой-либо внятный трафик не получается - слишком много переключений контекста. Я уже не говорю о том, что iperf сделан через жопу: управлять трафиком TCP можно только хаками. Сейчас буду смотреть в сторону pktgen. Может заодно и ВЛАНы будут не нужны. Изменено 2 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 14 мая, 2014 (изменено) · Жалоба Нашел вменяемый netperf. Абслютно та же проблема: трафик попадает в одну очередь. Написал в e1000-devel мейллист, но никто ничего не отвечает. Куда копать не понятно, будет ли эта же проблема на реальном трафике - тоже не ясно. Поведение драйвера и того что написано в DS - отличается. Ну да и важный момент: без PPPoE всё работает как надо. UPD. Короче походу всё очень грустно для PPPoE и других видов туннелей: говорят, мол, прибивайте ВЛАНы через VF, тогда можно будет руками распихать разные ВЛАны в разные очереди. Что делать в продакшене с этим делом - не понятно. Всё что не IP - не рулится ни Flow director, ни 5-tuple filter, но зато должно рулиться RSS, в нем тунелированные соединения трактуются как IP пакеты. В хеш попадают Source IP и Destination IP из L2 заголовка. Наверное надо поковырять как менять регистр MRQC, в котором можно задавать функции парсинга пакета. Судя по всему, пакет не парсится, а в этом случае RSS index = 0. При отсутствии других хешей, это скидывание пакета в 0 очередь. Еще вариант - включить DCB и попробовать рулить QoS приоритетами в какую очередь совать пакет. Это правда даст возможность разрулить только 8 очередей. Ну и костыль, к тому же. Изменено 15 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 15 мая, 2014 · Жалоба ixia Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 16 мая, 2014 · Жалоба Выяснили, что RSS функция не отрабатывает потому что в PPPoE фрейме смещения SRC IP и DST IP другие, соответственно функция их не находит. Почему нельзя было сделать хеш по макам - мне, лично, не понятно. Вообщем пока решения проблемы нет: парни говорят, что надо юзать VMDq и прибивать парсинг L2 к виртуальным функциям ( VF ), но во-первых, у меня это чудо не заводится, а во-вторых не понятно как быть с этим в продакшене, где вланов нет, а мак адресов десятки тысяч. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 19 мая, 2014 (изменено) · Жалоба Решилось включением RPS. Я включал, чтобы все процессоры могли обрабатывають все очереди. Это не очень эффективно с точки зрения кеша, но для моих синтетических тестов этого вполне достаточно. Тесты гоняю netperf. Он тоже кривой, но там большая часть операций kernel-space засчет чего он умирает от csw намного медленее чем его братья по функциям. И документация у него не плохая. Изменено 19 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...