Перейти к содержимому
Калькуляторы

Dark_Angel

Активный участник
  • Публикации

    368
  • Зарегистрирован

  • Посещение

Все публикации пользователя Dark_Angel


  1. Вставлю свои полторы копейки: без профайлера это все вилами по воде. Причин может быть миллион. 82571L даже без RPS может прожевать где-то 200-300 Kpps на каком-нибудь Core2Duo. C RPS так вообще. Единственное во что она упрется, по сравнению с 82576 ( железные фичи отбросим ), так это размер входящего буфера, но это не ваш случай. Поэтому мой совет: разберитесь с установкой профайлера. Поставьте бинарник со статической линковкой, как советовали выше, например. А то лечите симптомы. Рискуете потратить кучу времени и проблему не решить. Или решить вот таким методом тыка и не понять как. Или проблема решится по стечению обстоятельств и вы подумаете, что решение было в отключении HT, хотя на самом деле это окажется не так. У меня в свое время была похожая проблема, разве что оборудование и софт был другой. Вывод из безсонных ночей проведенных за копаниями: только профайлер.
  2. Я писал в мейлисты и чуваки мне отвечали с мылами @intel.com. Писали всякий бред про VMDq и другой неюзабельный, для текущей задачи, хлам. Потом пришел Эмиль Тантилов ( тоже @intel.com ) и отписался в конце-концов про RPS, после чего я написал, что не плохо бы в доке заапдейтить. После чего молчание. Вот тред кому интересно: http://sourceforge.net/p/e1000/mailman/e1000-devel/thread/27454542.6692.1400481996366.JavaMail.javamailuser%40localhost/#msg32353886 На самом деле у Интела нормальные доки и комьюнити, пусть и ответили позже чем здесь, так что я думаю, что апдейт будет в следующих ревизиях доки. А фикса в пару строк не будет, потому что выпиливать SRC IP, DST IP из туннелированного пакета - это накладно. Тут надо хешировать по маку, а у них юзается MSFT RSS, которая не умеет хешировать маки. И я не понимаю зачем было делать чтобы тунеллированные пакеты, скармливались RSS, если очевидно, что в тунеле смещения у SRC IP и DST IP будут другими для любой инкапсуляции. То есть по факту нерабочая логика в доке и в железке. В итоге при юзании RPS будет вымываться кеш процессора, т.к. пакеты из одного потока будут попадать на разные процессоры. Думаю оверхед такого решения будет значительным. Пока оценить не могу, т.к. проводил только синтетические тесты, а на них не видно.
  3. Странно в документации про то что соединения должны быть локальными ничего не говорится. Зато красиво рассказывается, как там анализируются хедеры, как в RSS. На каком ядре вы проводили тесты?
  4. Конечно нет. Я думаю, что достаточно большое количество сервисов работает на железках типа кошек и джунов, где свое железо и есть 40 и 100Г. Это я про телеком. Про контент ситуация похуже - там надо действительно покупать карты, но насколько велик спрос - не известно. Говорю к тому, что оценить размер рынка 10Г карт интела - сложно. А понять насколько велика доля карт для PPPoE серверов - еще сложнее. С другой стороны, если всё работает с RPS Интел может разрулить ситуацию просто апдейтом к документации. Что тоже не плохо, кстати. Однако RPS и RFS ( чтобы работало как RSS или как ntuple filter ) даст оверхед, то есть однозначно хуже хардварного решения. Ну оно для таких карт и было сделано. Если есть очереди и RSS работает нормально, то RPS не нужен. А так он и на риалтеках работает. Другой вопрос, что не все драйверах можно удобно крутить настройки. У интела можно всё гибко отрегулировать и упереться в процессоры или порты. В других картах, не предназначеных для этого можно начать ловить переполнение PHY или наоброт прерывание на каждый пакет дающим чудовищный оверхед. И, кстати, с RPS не плохо бы включать RFS, потому что без него будет большое количество cache_miss и в итоге Ксеоны превратятся в какие-нибудь дуал коры с малым кешем, если задача не тупой пакет форвардинг.
  5. Я не думаю, что рынок этих карт вообще велик, поэтому мне сложно судить 1000-2000 в год это много или мало. Я лишь пытался указать на тот факт, что юзкейс есть. И чтобы его сделать возможным нужно всего лишь добавить еще одну функцию парсинга в чип. Я не думаю, что эта задача сложна и стоит больше, чем возможная выгода. На 82579 же сделали и не обломались. Мне вообще кажется, что это больше ошибка и недочет, нежели специальное исключение функции по каким-то соображениям. То есть банальная недоработка. Иначе в доке было бы написано: юзайте RPS. Тем временем в доке эти выводы можно сделать только косвенным путем потратив уйму времени, как это сделал я.
  6. Решилось включением RPS. Я включал, чтобы все процессоры могли обрабатывають все очереди. Это не очень эффективно с точки зрения кеша, но для моих синтетических тестов этого вполне достаточно. Тесты гоняю netperf. Он тоже кривой, но там большая часть операций kernel-space засчет чего он умирает от csw намного медленее чем его братья по функциям. И документация у него не плохая.
  7. Я вас пытаюсь понять, но не могу. А что, PPPoE брасы у ex-USSR ISP - это не бизнес-кейс? Ну и чтобы 2 раза не вставать: c RPS всё работает как надо.
  8. Речь о том, что делать специально кол-во портов = кол-во процессоров - это странно. Насчет того что нет 10Г карт дешевых, ну так это же bleeding edge. Еще немного времени пройдет и появятся. Интел как раз к этому времени сделает 100Г. Насчет реального кейса - не соглашусь. Не забывайте, что сервера разные бывают. Самосбор, конечно, никто не ставит, но это не значит, что в брендовых серверах стоить что-то не 82599. И эти сервера от кошек или джуниперов по поддержке железа ничем не отличаются. А софт свой, например. Чем не юзкейс? Другой вопрос распостраненность PPPoE и других туннелей, но тут возникает вопрос к разработчикам чипа тогда: зачем было городить такой огород фильтров, если вы не умеете фильтровать L2. Вернее они умеют, но только через VF ( как юзать в продакшене не ясно ). А ntuple фильтры и Flow director, которые L3/L4 - умеют только UDP и только по 4ем полям. У L2 смещения не меняются и вообще всё хорошо, хешируй куда хочешь. Внимание ответ: потому что по спецификации MS в хеши RSS не входят заголовки L2, а до L3 мы добраться не можем, ибо туннель. Ну то есть в этом свете, для меня "нет реальных юзкейсов для балансировки L2" выглядит как попытка выгородить это кривое поделие. Случай может и вырожденный, но это не значит что он выдуман и невозможен в бизнесе.
  9. Ну это не проще, а странно. Зачем покупать сетевуху за много денег, которая умеет 128 очередей, если можно купить риалтек? Там тоже одна очередь на порт. По теме: в мейлистах e1000-devel признались, что надо юзать RPS и спихнули вину за кривой RSS на майкрософт, по спецификации которого это якобы сделано. Вообщем буду пробовать RPS, отпишусь.
  10. Есть и работают на 82579 - сервера в продакшене стоят - всё отлично. Работает из коробки без RPS и вообще без бубнов. Ядро 2.6.27. RPS существенно на тестах производительность не роняет? Все же это происходит на уровне софта, а не железки. Пусть и в пространстве ядра. Нельзя, потому что ntuple пропускает тунелированные пакеты, это первое, а во-вторых, никто, ни ntuple, ни Flow Director не умеют L2. Можно только через VF, которые у меня не заработали. Впрочем, я не представляю как это сделать на продакшене без костылинга.
  11. Понимаете, тут есть тонкий момент. PPPoE трафик без проблем балансится на 82579. Для меня было совершенно неожиданно то, что на 82599, который более продвинутый, типа, это нерешаемая задача ( RPS это уже из арсенала ОС а не самой карты ). Поэтому в теории да: включили RPS, вставили любой риалтек и всё заработало. Но, как говорится, может быть нюанс. Поэтому если кто-то собирал именно сабж - мне было бы интересно послушать мнение этого человека.
  12. Ну я с вами не согласен насчет того что, что это написано в документации. Я, например, чтобы докопаться до истины потратил достаточно не мало времени. Прочитав документацию и разобрав её до битов пакета такой вывод можно сделать, да. Было бы там предложение, что "чуваки, любое туннелирование у нас по очередям не балансится" - вопросов бы вообще не было. Более того, вы первый, кто говорит мне о том, что это есть в документации. На предмет RPS посмотрю, спасибо. Ну а вы или NiTr0 делали сабж? С RPS всё работает как надо?
  13. Выяснили, что RSS функция не отрабатывает потому что в PPPoE фрейме смещения SRC IP и DST IP другие, соответственно функция их не находит. Почему нельзя было сделать хеш по макам - мне, лично, не понятно. Вообщем пока решения проблемы нет: парни говорят, что надо юзать VMDq и прибивать парсинг L2 к виртуальным функциям ( VF ), но во-первых, у меня это чудо не заводится, а во-вторых не понятно как быть с этим в продакшене, где вланов нет, а мак адресов десятки тысяч.
  14. Всем привет. Решил создать отдельную тему, производную от этой: http://forum.nag.ru/forum/index.php?showtopic=91313 Суть проблемы: карта на 82599 чипе не распределяет по очередям трафик, если он PPPoE. Я проводил синтетические тесты, но на реальных тестах должно быть тоже самое. Трафик может быть с разных IP, VLAN, MAC и всего остального - это роли не играет - все пакеты попадают в первую очередь. Ядро, драйвера свежие. Есть ли такие на форуме, кто собирал такой сервер с такой картой? Была ли такая же проблема? Поделитесь опытом, пожалуйста.
  15. Нашел вменяемый 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 очередей. Ну и костыль, к тому же.
  16. Ну в итоге так и получается. Нагенерить какой-либо внятный трафик не получается - слишком много переключений контекста. Я уже не говорю о том, что iperf сделан через жопу: управлять трафиком TCP можно только хаками. Сейчас буду смотреть в сторону pktgen. Может заодно и ВЛАНы будут не нужны.
  17. Почитал доку, мейл листы и это просто грусть какая-то. Карта может много, но драйвера за ней не успевают ( а иногда просто кривые ). В итоге я не один с такой проблемой. Как строиться хеш RSS рассказано красиво и с картинками в DS, вот только на практике пакеты в начале ( до 80-го байта ) отличаются, пусть и не на много. А RSS хеш получается у них одинаковый? Но судя по диаграмме распределения пакетов, во-первых очередь может определить ether type, во-вторых туннелированные пакеты у flow director`a в матчинге не учавствуют. Но на всём этом фоне тогда не понятно как удается всё размазать пингу. Ведь туннелирование, хеш RSS и пр. - всё на месте. По маку по очередям распихивать нельзя, умеет только L4. И то очень ограниченый. Буду пробовать с ВЛАНами, т.к. тег - единственный доступный для распихивания по очередям инструмент, который по идее должен работать. UPD. ВЛАНЫ не помогают. Пакеты тупо не попадают к Flow director. Видимо мне прямой путь в mails list. UPD2. Если генерить TCP, то всё размазывается без Flow director по хешу RSS. Попробую что-то сделать через TCP.
  18. Да, поддерживается и это следующий инструмент, который я хочу попробовать после того как разберусь, почему дофолт не работает. Вариант, но может оказаться, что проще будет собрать скрипт на pktgen, нежели патчить iperf. Вообще iperf меня удивил своей негибкостью. До этих экспериментов я думал, что если мне что-то надо будет поменять по скорости, то: вот он инструмент мечты, а по факту оказалось, что максимум что там можно крутить - это порт/хост у клиент/сервер, размер пакета и скорость. Чего для "глубокой аналитики" недостаточно, очевидно. Про user-space умолчим. Я вот не уверен, что смогу нагенерить 1Mpps, ибо 500Kpps, уже дает 70% нагрузки на генераторе.
  19. Умеет, включил, но ничего не дало. Потому что UDP ( а у нас же PPPoE фреймы ). Другие опции хеширования и вообще TCP фрагментацию не умеет, судя по доке. Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма.
  20. Да, но тут нужно понимать еще, что пинг генерит разные пакеты внутри, а iperf скорее всего одинаковые. Ну и Flow Directory пофигу что внутри фрейма PPPoE - он берет заголовки только внешнего пакета. Соответственно в этой ситуации еще более не понятно почему ICMP нормальный, а UDP - нет. Щас попробую еще TCP, но там потоком сложнее управлять. UPD. У TCP тоже самое.
  21. Ну а чего же с добрыми людьми не поделится? Но с очередями по прежнему шляпа. Сделал macvlan на генераторе пакетов, назначил ИПшнички, то есть src_ip другой и маки другие. Всеравно всё сливается в одну очередь на роутере. То что пакеты идут с разных маков видно на интерфейсе роутера. Это iperf. Пинг по прежнему отжирает слишком много ресурсов, но пакеты по очередям размзывает даже без всяких macvlan. Пока не понятно что делать.
  22. Поменял ядро на генераторе ( 3.12.х ). Ситуация стала примерно в миллиард раз лучше.
  23. Спасибо за линк. Рамы у меня 16 Гб должно хватить на 15-16К сессий. Для моего теста - этого достаточно. Попробую другие ядра. О результате отпишусь, может быть ядерный клиент и не нужен будет.
  24. Да, у меня 3.2.23, но токое же ядро у PPPoE сервера и ему нормально. Рекомендуете проапдейтится?
  25. Я смотрел в сторону pktgen, но я для этого тестирования его использование вызывает больше вопросов, чем ответов. Для тестирования походу прийдется полностью реализовывать протокол pppoe ( хотябы на уровне сборки пакета ), а тем временем, например 2К сессий на клиенте уже делают 50% занятости CPU без всякой нагрузки. Наставить клиентов проблематично. Я тестирую, например, на 2х процессорном Xeon ( 16 ядер ), который не дешевый. Он уже умирает, если дать ему 4К клиентских сессий. При этом на сервере нагрузку вообще не видно. Уже не говоря о том, что сейчас сервера соеденены напрямую, а для нескольких клиентов надо будет ставить свитч. В идеале это клиент pppoe в kernel mode + iperf + macvlan чтобы всё по картам размазывалось. Умеет pppoe kernel mode в клиенте? Гугл рассказывает только про серверную часть в kernel mode.