Jump to content
Калькуляторы

Новые дрова от Яндеха Под Фрю 7/8

Интересно, никто не в курсе - а проект вообще жив?

Или для 9ой фри дров уже не будет?

Share this post


Link to post
Share on other sites

Интересно, никто не в курсе - а проект вообще жив?

Или для 9ой фри дров уже не будет?

Яндекс на Линукс мигрирует. Разве что wawa из личного интереса сделает.

Share this post


Link to post
Share on other sites

Пруф?

Share this post


Link to post
Share on other sites

это про виртуализацию среды разработки.

а драйвера под девятку будут когда девятка чуть повзрослеет, если к тому времени ещё останутся машины с em-устройствами.

Share this post


Link to post
Share on other sites

Вопрос к "гуру": Может в 9.0 уже этот драйвер не нужен?

Share this post


Link to post
Share on other sites

После 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

Share this post


Link to post
Share on other sites

После 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

Share this post


Link to post
Share on other sites

Не очень понял смысла патча.

 

Если трафик non-ip, (то есть приходит в 1ю очередь карточки) - то у тебя по очевидным причинам это будет на одном CPU и никакой выгоды этот патч не несет.

Если трафик - IP и карточка приличная, то у тебя (например, igb) выставит M_FLOWID и номер очереди в качестве ID. И пакет и так будет обрабатываться внутри этой очереди/ядра (при наличии включенного direct).

 

Если в какой-то момент пакет улетает из обработки ISR, (например - шейп с задержкой), то вынимает его из очереди, очевидно, уже другой процессор и привязывать его обратно к старому - смысл довольно сомнительный.

Ну и да, netisr тоже умеет на M_FLOWID смотреть, для определения того, в какую очередь свою класть.

 

А так - netisr с восьмерки вообще не пилили, судя по svn логам.

Share this post


Link to post
Share on other sites

Не очень понял смысла патча.

 

Если трафик 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 РРРоЕ серверов мне показалось проще и надежнее, чем городить цепочку убертазиков каждый-под-задачу). Конечно-же гипертрейдинг не создает ядра, тут я самовнушением не занимаюсь, но вроде как процессору должно быть легче. Я не знаю досконально как архитектуру процессора так и ядро, могу быть не прав, это просто эксперименты в стиле "а вдруг можно лучше". Кстати, если есть вариант получить у системы идентификатор ядра-компаньйона по гипертрейдингу буду весьма благодарен за информацию куда копать.

Share this post


Link to post
Share on other sites

Ну и в случае критической нагрузки показалось полезным быстро выгружать пакеты из карточки и ставить их в очередь 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]);
}

Share this post


Link to post
Share on other sites
которое будет грести тяжелую задачу форвардинга

Форвадинг сам по себе лёгкий, см fastfwd, вроде в sys/netinet.

 

Вообще странно, нонешний netisr жрет 10-15-20% дополнительной нагрузки по сравнению с direct, это в результате какой-то искусстенный шейпер получился :)

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

Share this post


Link to post
Share on other sites

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

Можно, но зачем? Лучше честно перевести netisr на buf_ring, как и большинство сетевых драйверов.

Share this post


Link to post
Share on other sites

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

Можно, но зачем? Лучше честно перевести netisr на buf_ring, как и большинство сетевых драйверов.

Для этого мозгов нужно немного более, чем у меня есть.

 

Теоретически можно прогнать всех, кому не нужен нат через fastforwarding, оно хорошо и быстро, а кому нужен - завернуть в нетграф и организовать очередь там вокруг ng_nat, пусть толкутся. Заодно получится померять нагрузку, создаваемую натом, я так понял она в ng_queue вылезет. Не знаю насколько это повлияет на общую производительность, но попробовать никто не мешает.

Share this post


Link to post
Share on other sites

Для этого мозгов нужно немного более, чем у меня есть.

Это я больше для себя (и Ivan_83)

..и организовать очередь там вокруг ng_nat, пусть толкутся.

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

Это, кстати, еще одна мораль - не пихайте всех в один нат, а сделайте большую их пачку

Share this post


Link to post
Share on other sites

Для этого мозгов нужно немного более, чем у меня есть.

Это я больше для себя (и Ivan_83)

..и организовать очередь там вокруг ng_nat, пусть толкутся.

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

Это, кстати, еще одна мораль - не пихайте всех в один нат, а сделайте большую их пачку

У меня 16 натов, делал больше - прироста не видно.

Share this post


Link to post
Share on other sites
У меня 16 натов, делал больше - прироста не видно.

После переваливания за количество доступных процов прирост производительности уменьшается вплоть до обратного: активные потоки перестают драться за общие ресурсы, но увеличиваются промахи в кеши.

Share this post


Link to post
Share on other sites

Судя по тому, что с августа никто не ответил, новых дров под bsd9 не будет. Жаль.

Share this post


Link to post
Share on other sites

Сделал вот патчики для яндексовских драйверов версий 6.9 и 7.0 под 7-ку,

которые добавляют переменную hw.em.max_interrupt_rate control,

которая задается в loader.conf и позволяет изменять ограничение на максимальное количество прерываний для каждого из портов.

По-умолчанию оно захардкодено и составляет 8к в секунду, что непростительно мало. В igb драйверах такая крутилка есть, теперь будет и в em-yandex.

https://gist.github.com/4247737

Share this post


Link to post
Share on other sites

Если учесть что Яндекс перешел на Ubuntu Linux, то ему как то оптимизировать дрова под фрю...

Поделился своим мнением сетевой инженер и программист компании Сергей Матвейчук: «Администрация не имела возражений против Free BSD, но разработчики и программисты выразили желание перейти на ОС Linux, потому как они не хотят разбираться и оптимизировать все разработки под Free BSD».

Share this post


Link to post
Share on other sites

После 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.

Иногда очень нужно бывает...

Edited by XaTTa6bl4

Share this post


Link to post
Share on other sites

Стало очень трудно сейчас найти последние версии (http://people.yandex-team.ru/~wawa/ отключен на веки, судя по всему)

 

Связался с товарищем, который работает в Яндексе...

Открылась истина: http://people.yandex.net/~wawa/

Пользуйтесь!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this