morom Опубликовано 13 января, 2012 · Жалоба Интересно, никто не в курсе - а проект вообще жив? Или для 9ой фри дров уже не будет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 13 января, 2012 · Жалоба Интересно, никто не в курсе - а проект вообще жив? Или для 9ой фри дров уже не будет? Яндекс на Линукс мигрирует. Разве что wawa из личного интереса сделает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 13 января, 2012 · Жалоба Пруф? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kapa Опубликовано 13 января, 2012 · Жалоба Пруф? http://smartsourcing.ru/blogs/otraslevye_novosti_i_sobytiya/783 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wawa Опубликовано 13 января, 2012 · Жалоба http://smartsourcing.ru/blogs/otraslevye_novosti_i_sobytiya/783 это про виртуализацию среды разработки. а драйвера под девятку будут когда девятка чуть повзрослеет, если к тому времени ещё останутся машины с em-устройствами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Daniil_ Опубликовано 3 апреля, 2012 · Жалоба После em-7.1.9-RELENG8-yandex-1.36.2.17.2.25 что то свежее появилось под 8-ку? http://people.yandex-team.ru/~wawa/ - починят? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lllsergeyv Опубликовано 4 апреля, 2012 · Жалоба Вопрос к "гуру": Может в 9.0 уже этот драйвер не нужен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 4 апреля, 2012 · Жалоба После em-7.1.9-RELENG8-yandex-1.36.2.17.2.25 что то свежее появилось под 8-ку? http://people.yandex-team.ru/~wawa/ - починят? :) Появилось, на днях выложим. И драйвер таки нужен. Другое дело, что разница может быть заметной начиная с 300-400kpps, чего на em бывает редко. это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно net.isr.numthreads: 4 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 Настройками не поделюсь, не рулится оно простыми sysctl. Для нормального распаралеливания нужен нормальный flowid, я его рассчитал примерно вот так: ... case ETHERTYPE_ARP: Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то. http://static.ipfw.ru/patches/netisr_ip_flowid.diff Я скорее всего через какое-то время закоммичу это в базу. Пока проблема в том, что и сам netisr тоже надо переписывать, на buf_ring(9), вместо очередей с мьютексом - с ним производительность проседает процентов на 20 от direct isr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 4 апреля, 2012 · Жалоба После em-7.1.9-RELENG8-yandex-1.36.2.17.2.25 что то свежее появилось под 8-ку? http://people.yandex-team.ru/~wawa/ - починят? :) Появилось, на днях выложим. И драйвер таки нужен. Другое дело, что разница может быть заметной начиная с 300-400kpps, чего на em бывает редко. это какая версия? Настройками не поделитесь? У меня если взять дефолтные дрова на 8.2 картина выглядит как-то вовсе безрадостно net.isr.numthreads: 4 net.isr.bindthreads: 0 net.isr.maxthreads: 4 net.isr.direct: 0 net.isr.direct_force: 0 Настройками не поделюсь, не рулится оно простыми sysctl. Для нормального распаралеливания нужен нормальный flowid, я его рассчитал примерно вот так: ... case ETHERTYPE_ARP: Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то. http://static.ipfw.ru/patches/netisr_ip_flowid.diff Я скорее всего через какое-то время закоммичу это в базу. Пока проблема в том, что и сам netisr тоже надо переписывать, на buf_ring(9), вместо очередей с мьютексом - с ним производительность проседает процентов на 20 от direct isr Я на 9-stable перевел рутера, там netisr допиливали в плане кучи очередей, нарисовал себе вот такой-вот патчик. Основной смысл - привязать пакет к cpu на котором он первый попал в машинку и дальше обрабатывать его только на этом cpu. Как обычно кривовато, навреное засунувшему грязные руки в mbuf их должно оторвать по самые пятки, но у меня в бою 100 кппс на карточку молотит нормально, аптайм пока месяц. А есть ли какое более элегантное решение сохранить меточку в mbuf? А то я где нашел там и прилепил. isr.diff.txt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 4 апреля, 2012 · Жалоба Не очень понял смысла патча. Если трафик non-ip, (то есть приходит в 1ю очередь карточки) - то у тебя по очевидным причинам это будет на одном CPU и никакой выгоды этот патч не несет. Если трафик - IP и карточка приличная, то у тебя (например, igb) выставит M_FLOWID и номер очереди в качестве ID. И пакет и так будет обрабатываться внутри этой очереди/ядра (при наличии включенного direct). Если в какой-то момент пакет улетает из обработки ISR, (например - шейп с задержкой), то вынимает его из очереди, очевидно, уже другой процессор и привязывать его обратно к старому - смысл довольно сомнительный. Ну и да, netisr тоже умеет на M_FLOWID смотреть, для определения того, в какую очередь свою класть. А так - netisr с восьмерки вообще не пилили, судя по svn логам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 5 апреля, 2012 · Жалоба Не очень понял смысла патча. Если трафик non-ip, (то есть приходит в 1ю очередь карточки) - то у тебя по очевидным причинам это будет на одном CPU и никакой выгоды этот патч не несет. Если трафик - IP и карточка приличная, то у тебя (например, igb) выставит M_FLOWID и номер очереди в качестве ID. И пакет и так будет обрабатываться внутри этой очереди/ядра (при наличии включенного direct). Если в какой-то момент пакет улетает из обработки ISR, (например - шейп с задержкой), то вынимает его из очереди, очевидно, уже другой процессор и привязывать его обратно к старому - смысл довольно сомнительный. Ну и да, netisr тоже умеет на M_FLOWID смотреть, для определения того, в какую очередь свою класть. А так - netisr с восьмерки вообще не пилили, судя по svn логам. Насчет пилили или не пилили - заглянул в код а там новое появилось, может из-за того, что не особо свежая 8 использовалась я и не видел этого. Идея была привязать обработку пакета к ядру процессора с момента получения прерывания, и до постановки в очередь на отправку, ну а вдруг там кеш оптимальнее использоваться будет и наступит щастье. Карточки у меня в машинках и em и igb, igb работают в 1 поток - всеравно PPPoЕ молотят, прерывания от них развешаны cpuset - каждой карточке свое ядро, поэтому брал curcpu как исходные данные для привязки. Железо возле рутера не особо хорошо трафик по портам раскладывает, тоже видать не умеет non-ip, из-за этого не симметрично проц грузится, igb0 может занимать 80% cpu когда igb1 60%, хотя оба они в lagg0, это судя по top. Ну и в случае критической нагрузки показалось полезным быстро выгружать пакеты из карточки и ставить их в очередь netisr которая намного длиннее, при этом растет задержка но ошибок на интерфейсе нет. Опять-же, следующим шагом - не бейте меня сильно - планировалось включить гипертрейдинг на рутере. Типа ядро 0 будет быстренько обрабатывать прерывания и складывать пакеты для netisr в очередь для ядра 1, которое будет грести тяжелую задачу форвардинга с натом (тоже не бейте сильно, но поставить 20 РРРоЕ серверов мне показалось проще и надежнее, чем городить цепочку убертазиков каждый-под-задачу). Конечно-же гипертрейдинг не создает ядра, тут я самовнушением не занимаюсь, но вроде как процессору должно быть легче. Я не знаю досконально как архитектуру процессора так и ядро, могу быть не прав, это просто эксперименты в стиле "а вдруг можно лучше". Кстати, если есть вариант получить у системы идентификатор ядра-компаньйона по гипертрейдингу буду весьма благодарен за информацию куда копать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 6 апреля, 2012 · Жалоба Ну и в случае критической нагрузки показалось полезным быстро выгружать пакеты из карточки и ставить их в очередь netisr которая намного длиннее, при этом растет задержка но ошибок на интерфейсе нет. Вообще странно, нонешний netisr жрет 10-15-20% дополнительной нагрузки по сравнению с direct, это в результате какой-то искусстенный шейпер получился :) Но если очень хочется - можно вместо дополнительных флагов выставлять M_FLOWID и m->m_pkthdr.flowid в curcpu там же. В netisr код простой - u_int netisr_default_flow2cpu(u_int flowid) { return (nws_array[flowid % nws_count]); } Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 апреля, 2012 · Жалоба которое будет грести тяжелую задачу форвардинга Форвадинг сам по себе лёгкий, см fastfwd, вроде в sys/netinet. Вообще странно, нонешний netisr жрет 10-15-20% дополнительной нагрузки по сравнению с direct, это в результате какой-то искусстенный шейпер получился :) Можно сделать "пустую" ноду, которая просто пересылает пакеты между хуками, выставить HK_QUEUE на оба хука и получить тот же netisr с раскидыванием по процам из общей очереди но средствами нетграфа, сам нетиср в директ поставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 6 апреля, 2012 · Жалоба Можно сделать "пустую" ноду, которая просто пересылает пакеты между хуками, выставить HK_QUEUE на оба хука и получить тот же netisr с раскидыванием по процам из общей очереди но средствами нетграфа, сам нетиср в директ поставить. Можно, но зачем? Лучше честно перевести netisr на buf_ring, как и большинство сетевых драйверов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 6 апреля, 2012 · Жалоба Можно сделать "пустую" ноду, которая просто пересылает пакеты между хуками, выставить HK_QUEUE на оба хука и получить тот же netisr с раскидыванием по процам из общей очереди но средствами нетграфа, сам нетиср в директ поставить. Можно, но зачем? Лучше честно перевести netisr на buf_ring, как и большинство сетевых драйверов. Для этого мозгов нужно немного более, чем у меня есть. Теоретически можно прогнать всех, кому не нужен нат через fastforwarding, оно хорошо и быстро, а кому нужен - завернуть в нетграф и организовать очередь там вокруг ng_nat, пусть толкутся. Заодно получится померять нагрузку, создаваемую натом, я так понял она в ng_queue вылезет. Не знаю насколько это повлияет на общую производительность, но попробовать никто не мешает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 6 апреля, 2012 · Жалоба Для этого мозгов нужно немного более, чем у меня есть. Это я больше для себя (и Ivan_83) ..и организовать очередь там вокруг ng_nat, пусть толкутся. ng_nat и прочее libalias-based прямо из коробки без дополнительных ухищрений организует очередь из желающих - потому что защищается мьютексом, то есть не более одного пользователя одноврменно. Это, кстати, еще одна мораль - не пихайте всех в один нат, а сделайте большую их пачку Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 6 апреля, 2012 · Жалоба Для этого мозгов нужно немного более, чем у меня есть. Это я больше для себя (и Ivan_83) ..и организовать очередь там вокруг ng_nat, пусть толкутся. ng_nat и прочее libalias-based прямо из коробки без дополнительных ухищрений организует очередь из желающих - потому что защищается мьютексом, то есть не более одного пользователя одноврменно. Это, кстати, еще одна мораль - не пихайте всех в один нат, а сделайте большую их пачку У меня 16 натов, делал больше - прироста не видно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 апреля, 2012 · Жалоба У меня 16 натов, делал больше - прироста не видно. После переваливания за количество доступных процов прирост производительности уменьшается вплоть до обратного: активные потоки перестают драться за общие ресурсы, но увеличиваются промахи в кеши. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kibermaster Опубликовано 17 августа, 2012 · Жалоба Всем привет! Никто не знает, ожидается ли восстановление http://people.yandex-team.ru/~wawa/ ? И будут ли дрова под 9-ку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Daniil_ Опубликовано 7 октября, 2012 · Жалоба поднимая тему, никто не знает, когда поднимут сайт с дровами http://people.yandex-team.ru/~wawa/ ? или может в другое место уже переехали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kibermaster Опубликовано 8 декабря, 2012 · Жалоба Судя по тому, что с августа никто не ответил, новых дров под bsd9 не будет. Жаль. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mr.Scamp Опубликовано 10 декабря, 2012 · Жалоба Сделал вот патчики для яндексовских драйверов версий 6.9 и 7.0 под 7-ку, которые добавляют переменную hw.em.max_interrupt_rate control, которая задается в loader.conf и позволяет изменять ограничение на максимальное количество прерываний для каждого из портов. По-умолчанию оно захардкодено и составляет 8к в секунду, что непростительно мало. В igb драйверах такая крутилка есть, теперь будет и в em-yandex. https://gist.github.com/4247737 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 10 декабря, 2012 · Жалоба Если учесть что Яндекс перешел на Ubuntu Linux, то ему как то оптимизировать дрова под фрю... Поделился своим мнением сетевой инженер и программист компании Сергей Матвейчук: «Администрация не имела возражений против Free BSD, но разработчики и программисты выразили желание перейти на ОС Linux, потому как они не хотят разбираться и оптимизировать все разработки под Free BSD». Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XaTTa6bl4 Опубликовано 8 января, 2013 (изменено) · Жалоба После em-7.1.9-RELENG8-yandex-1.36.2.17.2.25 что то свежее появилось под 8-ку? http://people.yandex-team.ru/~wawa/ - починят? :) Появилось, на днях выложим. Стало очень трудно сейчас найти последние версии (http://people.yandex-team.ru/~wawa/ отключен на веки, судя по всему). Выложите, пожалуйста, еще раз куда-нибудь в паблик для 7-й и 8-й FreeBSD. Иногда очень нужно бывает... Изменено 8 января, 2013 пользователем XaTTa6bl4 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XaTTa6bl4 Опубликовано 10 января, 2013 · Жалоба Стало очень трудно сейчас найти последние версии (http://people.yandex-team.ru/~wawa/ отключен на веки, судя по всему) Связался с товарищем, который работает в Яндексе... Открылась истина: http://people.yandex.net/~wawa/ Пользуйтесь! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...