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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пруф?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

После em-7.1.9-RELENG8-yandex-1.36.2.17.2.25 что то свежее появилось под 8-ку?

http://people.yandex-team.ru/~wawa/ - починят? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

которое будет грести тяжелую задачу форвардинга

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем привет! Никто не знает, ожидается ли восстановление http://people.yandex-team.ru/~wawa/ ? И будут ли дрова под 9-ку?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

поднимая тему, никто не знает, когда поднимут сайт с дровами http://people.yandex-team.ru/~wawa/ ?

или может в другое место уже переехали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

https://gist.github.com/4247737

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем XaTTa6bl4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.