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

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

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

 

ddio_01.jpg

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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 напрямую забирает? А почему сразу не сделали в обе стороны?

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by vitalyb

Share this post


Link to post
Share on other sites

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Edited by Alex/AT

Share this post


Link to post
Share on other sites

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

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

С чего это?

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

Edited by DenKZ

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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, в последние ядра не смотрел.

Edited by Alex/AT

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