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

Обсуждаем новый Xeon E5 с DDIO

Присматриваем юнипроцессорную конфигурацию для очередного сервера доступа. Заинтересовала технология Data Direct I/O в обновленных ксеонах

 

ddio_01.jpg

 

Пишут что за счет прямой работы NIC с кэшем производительность удастся поднять на 10-20 процентов. При этом никакой дополнительной поддержки со стороны сетевухи или софта не требуется. Про сроки появления на прилавках серии 1ХХХ ничего не известно в то время как на ЯМ уже масса предложений по сериям 2XXX.

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


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

Не надо тут пугать людей такими страшными картинками, а то сейчас все от ужоса вырвут все волосы изподмышек. Как же мы всё это время работали с таким хауном?! :(

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


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

На самом деле есть какой-то маркетинговый нюанс в этой диаграмме, поскольку на тех же igb всё уже давно memory-mapped.

Изменено пользователем Alex/AT

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


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

На самом деле есть какой-то маркетинговый нюанс в этой диаграмме, поскольку на тех же igb всё уже давно memory-mapped.

 

Маркетинг здесь замешан по-любому. Жаль нет сравнительного тестирования для загруженных маршрутизаторов в открытом доступе. У нас на топовом Core i7 при 50% idle на всех ядрах наблюдается подозрительный рост load average. При этом весь тюнинг igb необходимый сделан, очереди грамотно раскидываются по ядрам и т.д. Где-то явно образуется bottleneck и это не nic и не cpu.

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


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

Получается, что

Direct Cache Access (DCA) allows a capable I/O device, such as a network controller, to place data directly into CPU cache, reducing cache misses and improving application response times.

кладет данные напрямую в кеш, а DDIO напрямую забирает? А почему сразу не сделали в обе стороны?

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


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

Пишут что за счет прямой работы NIC с кэшем производительность удастся поднять на 10-20 процентов.

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

Внутри процессора+ОЗУ и внутри сетевой всё останется по-прежнему.

Если у Вас не голый роутинг, то эти 20 процентов на общем фоне будут слабо заметны, скорее всего.

Поэтому используйте то, что есть в продаже, и не парьтесь.

Всё равно на новые модели Ксеонов цена всегда задрана до безобразия.

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


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

Возможно суть технологии в том, что устройства с MMIO наконец-то научили управлять линейками кеша процессора. Т.е. memory-mapped - это хорошо, но это на практике некешируемые регионы. Если они стали кешируемыми - вдвойне замечательно, но схема от интела выше всё равно отдает неадекватизмом, системная память при MMIO никаким боком не участвует :) Поэтому сий вариант не рассматриваем всерьез.

 

Либо более вероятный второй вариант - это отправка данных через кеш (когда буфер на отправку выделяется не в системной памяти, а в кеше). Теоретически чем-то лучше, чем стандартный SG с обращением к памяти через "DMA"/"BM", но фокус в том, что кеш в данном случае может быть только shared (очевидно, L3), поскольку аллокация буфера может начаться на одном ядре, и завершиться отправкой на другом (в отдельных случаях с прибивкой интов к ядрам), а L3 тоже не сильно эффективен. Ну и zero-copy с такими буферами получится только в пределах разве что именно тупого роутинга, когда фрейм в буфере не меняет длины, если идёт хоть какая-то инкапсуляция/декапсуляция, к примеру PPPoE, или просто передача приложению - в первом случае всё равно уже нужна поддержка SG, во втором - работа с системной памятью.

 

Кто-нибудь интересовался, SG (scatter-gather, в данном случае больше интересует именно gather, возможность "сборки" фрейма из кусочков, разрозненных по адресам в буферах) в данной технологии есть, или пока нет никакой дополнительной информации?

Изменено пользователем Alex/AT

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


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

Возможно суть технологии в том, что устройства с MMIO наконец-то научили управлять линейками кеша процессора

Судя со скринов, DMA научили кешироваться, в л3 по ходу... Сомневаюсь, что все именно так как на скрине (выделение памяти исключительно в кеше), более вероятно, что ИКП стал кешировать все запросы к памяти, а не только запросы процессорных ядер.

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


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

Кто-нибудь интересовался, SG (scatter-gather, в данном случае больше интересует именно gather, возможность "сборки" фрейма из кусочков, разрозненных по адресам в буферах) в данной технологии есть, или пока нет никакой дополнительной информации?

По идее SG исключительно фича сетевой карты - сможет ли собрать/разобрать фрейм по кускам или нет, и если никакой дополнительной поддержки действительно не нужно, думаю, должно работать.

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

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


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

Одно дело SG из системной памяти, другое дело - буфер в линейках кеша... Вот в том и вопрос - сможет оно переупорядочить данные из линейки кеша, или придётся софту собирать в этом буфере линейный фрейм.

Изменено пользователем Alex/AT

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


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

Объясните нубу - для NAT прирост будет?

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


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

Для больших инсталляций скорее всего нет - там узкое место в поддержании таблиц сессий. А вот там, где клиентов мало, а трафика много - может быть.

 

Ну и да - прирост будет не раньше, чем под это дело допилят драйверы.

Изменено пользователем Alex/AT

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


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

Поэтому используйте то, что есть в продаже, и не парьтесь.

Всё равно на новые модели Ксеонов цена всегда задрана до безобразия.

С чего это?

Цена на предыдущий E5620 такая-же как и на E5-2620... - $20 разницы не в счет...

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

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


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

Для больших инсталляций скорее всего нет - там узкое место в поддержании таблиц сессий.

 

А можно поподробнее этот момент осветить?

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


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

Да а чего его освещать:

static void
__nf_conntrack_confirm(struct sk_buff *skb)
...
spin_lock_bh(&nf_conntrack_lock);
...
static struct nf_conn *get_next_corpse(struct net *net, int (*iter)(struct nf_conn *i, void *data), void *data, unsigned int *bucket)
...
spin_lock_bh(&nf_conntrack_lock);

 

Всё остальное на RCU.

 

Только вот conntrack_confirm вызывается при переходе каждой новой сессии в подтвержденное состояние. А nf_ct_iterate_cleanup вызывает get_next_corpse в цикле для очистки таблицы сессий. На прогон трафика это не влияет, однако при огромном числе сессий падение производительности будет.

 

Сие было в 2.6.32, в последние ядра не смотрел.

Изменено пользователем Alex/AT

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


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

Join the conversation

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

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

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

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

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

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

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