дрова Yandex

[adeep 212]

После тестов пришол к выводу.

На ЕТ карточку, драйвера или интел не реализовал полностю чип, или "недоколихані", или производителем железа некоторые фишки спецом залочены и за дополнительные ххх баксов, на свет появится новая карта, естественно когда рынок насытится старыми.

На РТ, ситуация аналогичная, но гадский яндекс испортил всю малину и на яндекс драйвере возможна довольно полная реализация возможностей стандарта MSI.

В обойх случаях, карточки работают на 50-70% от возможностей.

 

Можете пояснить что именно у вас не заработало как хотелось? и что подразумевается под оставшимися 30-50% возможностей карт?

[pavlabor 1 939]

Что бы понять, немного отступления.

Интел карточка отличается от, скажем реалтека тем что,

- отработка прерываний производится самой карточкой, без задействования ресурсов процессора.

Освободившиеся ресурсы процессора можно использовать для других задач.

 

В системе ТОР, этот параметр отражается "% interrupt".

Индикатор использования ресурсов процессора для обработки прерываний, сетевой карты в том числе.

 

Так вот,

при использовании реалтека, нагрузка на interrupt, большая,

при использовании интела почти ноль.

 

Когда ставится карточка РТ или ЕТ, на стандартных дровах, interrupt большой,

================

last pid: 23409; load averages: 0.06, 0.07, 0.02 up 8+20:40:27 15:36:21

83 processes: 5 running, 59 sleeping, 19 waiting

CPU 0: 0.5% user, 0.0% nice, 3.2% system, 5.0% interrupt, 91.4% idle

CPU 1: 0.0% user, 0.0% nice, 37.1% system, 0.9% interrupt, 62.0% idle

CPU 2: 0.0% user, 0.0% nice, 0.5% system, 61.5% interrupt, 38.0% idle

CPU 3: 0.0% user, 0.0% nice, 0.0% system, 55.2% interrupt, 44.8% idle

Mem: 33M Active, 258M Inact, 456M Wired, 396K Cache, 417M Buf, 3145M Free

Swap: 8192M Total, 8192M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

13 root 1 171 ki31 0K 16K RUN 1 186.7H 97.46% idle: cpu1

14 root 1 171 ki31 0K 16K CPU0 0 194.7H 94.97% idle: cpu0

38 root 1 -68 - 0K 16K WAIT 3 90.4H 59.08% irq256: em0

12 root 1 171 ki31 0K 16K CPU2 2 131.5H 54.30% idle: cpu2

42 root 1 -68 - 0K 16K WAIT 2 80.7H 53.76% irq259: em1

11 root 1 171 ki31 0K 16K RUN 3 121.1H 42.58% idle: cpu3

43 root 1 -68 - 0K 16K WAIT 1 252:08 2.78% irq260: em1

================

та же самая ситуация

================

last pid: 15908; load averages: 0.31, 0.11, 0.03 up 8+20:31:07 15:21:48

80 processes: 4 running, 53 sleeping, 23 waiting

CPU 0: 0.0% user, 0.0% nice, 0.5% system, 60.0% interrupt, 39.5% idle

CPU 1: 0.0% user, 0.0% nice, 2.2% system, 54.1% interrupt, 43.8% idle

Mem: 342M Active, 537M Inact, 455M Wired, 272K Cache, 213M Buf, 638M Free

Swap: 4096M Total, 4096M Free

 

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND

11 root 1 171 ki31 0K 16K RUN 1 135.5H 51.66% idle: cpu1

12 root 1 171 ki31 0K 16K RUN 0 117.2H 36.96% idle: cpu0

27 root 1 -68 - 0K 16K WAIT 0 40.0H 28.47% irq258: igb0

29 root 1 -68 - 0K 16K CPU1 1 39.6H 26.37% irq259: igb0

================

 

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

Или, чип самостоятельно не полностю обрабатывает процедуру.

 

Если возратится к реалтеку и интелу, то снижение нагрузки на interrupt, практически к нулю,

свидетельствует о том что задача обработки прерывания реализована полностю аппаратно, на уровне чипа сетевой карты.

и поток в чистом виде передается на дельнейшую обработку операционке.

 

Реально, получается что текущая реализация ЕТ, находится на уровне старых дешовых сетевых карт,

производителность достигается за счет более продвинутого алгоритма MSI-X,

при этом аппаратно задача полностю не решается,

дополнительно задействуются ресурсы процессоров, реально выжирает 50-60%.

То есть ерунда какаято.

 

Вот собственно и все.

Почему так, сложно сказать.

В полне вероятно, что разработчики заинтересованы в продаже мощного железа,

потому как с тем что декларировано а протоколе MSI-X,

гиг транзитом можно раскачать при 2-х ядрах скажем по 2гигагерца,

еще хватит на фаервол скажем правил в 10тысяч.

 

Если не залочено на аппаратном уровне, то возможно появится драйвер,

в чем есть сомнения.

 

Поетому следует ожидать новую карточку, которая реально будет обрабатывать поток на аппаратном уровне,

и покажет interrupt близкий к нулю.

[Dragon 13]

Собственно домашняя страница разработчика

http://people.yandex-team.ru/~wawa/

[adeep 212]

IMHO, вы не совсем поняли что такое interrupt. Это обработка пакета, да. Но это полная обработка пакета, маршрутизация, файрволинг и прочее. Обработка может проходить или в системе isr или сразу по принятию пакета. И в данном случае прелесть интела является в том, что они могут подсчитать контрольную сумму заголовка, определить его корректность и сложить в буфер из которого потом пакеты достанутся пачкой.

Именно из-за последнего невооруженным взглядом виден прогресс эффективности обработки по сравнению с реалтеками. Потому что при обработке по прерыванию на пакет вход-выход в прерывание является очень весомой частью.

 

И в данном случае MSI-X лишь позволяет устроить обработку несколькими параллельными обработчиками, которыми будет управлять сама карточка.

[pavlabor 1 939]

interrupt - это показатель затрат ресурсов процесора на обработку прерываня,

сюда входят все прерывания который требуют помощи процесора,

то есть полное выполнение процедуры принятия пакета.

После обработки задачи принятия пакета, пакет уходит на обработку системе,

если IPFW ядерный, нагрузка будет отражатся system,

если IPFW не ядерный, нагрузка отражается параметром user.

 

Комп, напакован аппаратными интерфейсами, которые имеет разный уровень самодостаточности,

и их задача принимать или отдавать поток данный готовый для дальнейшей обработки системой.

 

То что проц "вынужден" участвовать в обработке пакета, не относится к показателю interrupt.

Например.

Ставим генератор и гоним трафик,

Дешовая карточка реалтек - 30% interrupt

Интел старая стандартная карточка - 0% interrupt

ЕТ - 4% interrupt

структура трафика и набор правил не меняется.

Вопрос, почему при использовании реалитека и карточуи ЕТ, требуется ресурсы проца,

а в старой интеловской карте, нет?

 

Думаю не сложно понять что старый интел аппаратно выполняет прием пакета и дальнейший поток уже светится на пользовательской или системной нагрузке, а реалтек и ЕТ, не в состоянии обойтись своими ресурсами и привлекает расчетные мощности центрального проца.

 

То есть ЕТ ведет себя как карточка реалтека, а производительность выросла, только за счет использования новой технологии обработки пакета.

Когда доработают чип, или чо-то там разлочат, карточка будет сама работать с потоком, interrupt будет близок к нулю,

а освободившиеся расчетные ресурсы, пойдут на другие задачи.

 

А возможно косяк с мостами, с процом.

Возможно нужно дополнительно включать поддержку.

Но сейчас нет связки!

[pavlabor 1 939]

И в данном случае MSI-X лишь позволяет устроить обработку несколькими параллельными обработчиками, которыми будет управлять сама карточка.

 

Согласно анонсам, карточка должна уметь

- самостоятельно выбрать ядро для работы,

- принять пакет(такие мелочи как проверка контрольной суммы даже не оговаривается), пройти мост и положить его в память, ДМА,

- поднять флаг прерывания что пакет готов у обработке.

 

ОС-и остается просто отдать следующему приложению адрес памяти где находится пакет.

И вот тут, похоже что что-то карточка не в состоянии сделать и вынуждена просить проц помогать.

На самом деле, задача может и не затратная, но учитывая количества трафика, interrupt и прыгает не по детски.

[adeep 212]

Согласно анонсам, карточка должна уметь

- самостоятельно выбрать ядро для работы,

вы серьезно думаете, что кто-то будет делать драйвера, которые будут плевать на системный планировщик процессов?

 

- принять пакет(такие мелочи как проверка контрольной суммы даже не оговаривается), пройти мост и положить его в память, ДМА,

- поднять флаг прерывания что пакет готов у обработке.

в том то и дело, что это мелочи. самое дорогое из этого - прерывание. потому что оно безусловно переводит процессор в режим ядра, сохраняет состояние всех регистров и стека и только после этого идет обработка пакета.

 

ОС-и остается просто отдать следующему приложению адрес памяти где находится пакет.

следующее приложение - это драйвера карты и ядро ОС. причем обработка может вестись и внутри обработчика прерывания, и вне его.

 

И вот тут, похоже что что-то карточка не в состоянии сделать и вынуждена просить проц помогать.

она делает все, что требуется: пакет приняла, в буфер положила, прерывание дернула. TSO, контрольные суммы заголовков в качестве бонуса.

[KaYot 3 707]

interrupt - это показатель затрат ресурсов процесора на обработку прерываня,

сюда входят все прерывания который требуют помощи процесора,

то есть полное выполнение процедуры принятия пакета.

После обработки задачи принятия пакета, пакет уходит на обработку системе,

если IPFW ядерный, нагрузка будет отражатся system,

IMHO не верно. interrupt в вашем случае это hard+soft interrupts видимо, сюда входит все включая ядерный NAT..

В линуксовом ТОПе идут отдельно int и soft int, на именно аппаратные прерывания в 99% случаев можно не смотреть вообще, там нули, а soft int как раз таки и показывает загрузку от фаервола/NATa/iproute и т.п. вещей участвующих в обработке пакетов.

[pavlabor 1 939]

Согласно анонсам, карточка должна уметь

- самостоятельно выбрать ядро для работы,

вы серьезно думаете, что кто-то будет делать драйвера, которые будут плевать на системный планировщик процессов?

 

Интел давно анонсировал реализацию

Multiple queues, RSS, MSI-X, and VMDq working together in a multi-core system

 

http://download.intel.com/support/network/sb/318483001us2.pdf

 

В настоящее время интел ведет работы по созданию подобия фабрики коммутации в свичах.

Работы, как по мне, идут довольно успешно.

Еще год-два и цыску всадят на скоростях 10гиг.

Уже сегодня в секторе 1 гиг, смысла нет использовать аппаратный роутер.

 

Проблема в том что продвинутые карточки кроме интела, как бы никто и не делает.

 

Без аппаратной реализации RSS, MSI-X, and VMDq за 10 гиг можно и не мечтать.

Согласно анонсов, все как бы уже было реализовано в чипе 82575.

Но лично меня тесты в этом не убедили.

 

И повторюсь, или педалей не нащупал, или спецом залочено.

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

Потому что еще раз повторюсь, при аппаратной реализации RSS, MSI-X, and VMDq, гиг можно роутить пеньком в 3 гигагерца.

Это интересно всем, кроме интела.

[KaYot 3 707]

Проблема в том что продвинутые карточки кроме интела, как бы никто и не делает.

Да ладно, тот же Broadcom делает вполне себе аналоги интеловской ET с очередями и всеми плюшками.

[pavlabor 1 939]

Проблема в том что продвинутые карточки кроме интела, как бы никто и не делает.

Да ладно, тот же Broadcom делает вполне себе аналоги интеловской ET с очередями и всеми плюшками.

 

Брадком, да, он прошол 70% дистанции которую прошол интел.

Остальные 30%.

Лопатят бабосы с сегмента домашних компов, и этого хватает с головой.

[adeep 212]

И повторюсь, или педалей не нащупал, или спецом залочено.

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

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

причем Multiple queues, RSS, MSI-X по сути результата (несколько очередей обработки пакетов) являются одной и той же технологией.

а VMDq вообще не имеет отношения роутингу в случае когда не используется виртуализация.

 

 

Потому что еще раз повторюсь, при аппаратной реализации RSS, MSI-X, and VMDq, гиг можно роутить пеньком в 3 гигагерца.

откуда вы это взяли?

[adeep 212]

Да ладно, тот же Broadcom делает вполне себе аналоги интеловской ET с очередями и всеми плюшками.

К сожалению у броадкома нет программистов, которые имели бы статус коммитера freebsd и занимались именно реализацией драйверов под фрю

[KaYot 3 707]

Да ладно, тот же Broadcom делает вполне себе аналоги интеловской ET с очередями и всеми плюшками.

К сожалению у броадкома нет программистов, которые имели бы статус коммитера freebsd и занимались именно реализацией драйверов под фрю

Ну я вижу что под bsd с дровами и на интеловские карточки не все ок)

[adeep 212]

Ну я вижу что под bsd с дровами и на интеловские карточки не все ок)

BSD денег не платит)) в отличие от мелкософта) и опять же имееет меньшую популярность, чем тот же линукс.

[pavlabor 1 939]

И повторюсь, или педалей не нащупал, или спецом залочено.

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

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

причем Multiple queues, RSS, MSI-X по сути результата (несколько очередей обработки пакетов) являются одной и той же технологией.

а VMDq вообще не имеет отношения роутингу в случае когда не используется виртуализация.

 

 

Потому что еще раз повторюсь, при аппаратной реализации RSS, MSI-X, and VMDq, гиг можно роутить пеньком в 3 гигагерца.

откуда вы это взяли?

 

Я до сих пор занимаюсь разработкой коммутаторов и могу интуитивно определить что можно выжать при разных технологических решениях.

[adeep 212]

Я до сих пор занимаюсь разработкой коммутаторов и могу интуитивно определить что можно выжать при разных технологических решениях.

Так надо немного различать задачи коммутаторов по переброске L2 пакетов из порта в порт на специализированных чипах от задач маршрутизации и обработки траффика на неспециализированных операционных системах и процессорах общего назначения.

[pavlabor 1 939]

Я до сих пор занимаюсь разработкой коммутаторов и могу интуитивно определить что можно выжать при разных технологических решениях.

Так надо немного различать задачи коммутаторов по переброске L2 пакетов из порта в порт на специализированных чипах от задач маршрутизации и обработки траффика на неспециализированных операционных системах и процессорах общего назначения.

 

L2 - это прошлый век?

[adeep 212]

L2 - это прошлый век?

Причем здесь это?

на PC-роутерах задачи L2 в большинстве случаев не решаются по причине отсутствия необходимости и особенностей реализации.

[pavlabor 1 939]

L2 - это прошлый век?

Причем здесь это?

на PC-роутерах задачи L2 в большинстве случаев не решаются по причине отсутствия необходимости и особенностей реализации.

 

Нельзя не решить задачу L2, решая задачи L3 и выше.

[KaYot 3 707]

А зачем ее решать на серверах?

[adeep 212]

Нельзя не решить задачу L2, решая задачи L3 и выше.

простите, какую задачу L2 вы решаете на серверах? принять пакет? это делает сетевушка и не нагружает процессор никак.

все остальное - это обработка пакета.

[pavlabor 1 939]

А зачем ее решать на серверах?

 

Хм...

наверно затем, что тому же нату нужен не езернет пакет.

 

Не решатся задача РС сервером не может.

Какая разница кто и как это решает?

Всеравно за писюк никто этого не делает.

[KaYot 3 707]

А зачем ее решать на серверах?

 

Хм...

наверно затем, что тому же нату нужен не езернет пакет.

И квипу пакеты не нужны. Не вижу логики.

[adeep 212]

Хм...

наверно затем, что тому же нату нужен не езернет пакет.

Вы ушли в сторону. Под задачами L2 свича подразумевалось: выбор макадреса и маршрутизация L2 пакета по макадресу в нужный порт. всевозможные блокировки по макам, src/dst адресам и портам (несмотря на то что они залазят в L3) на деле в свичах решаются простейшими сравнениями битовых масок на уровне специализированных чипов.

Эти задачи в PC-роутере фактически не решаются.

Решаются задачи в основном роутинга пакета на основе L3 информации и правил файрвола. Что подразумевает под собой полную разборку пакета по заголовкам и обработку оного.