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

[kaN5300]

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

 

 

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

[edgars]

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

[Alex/AT]

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

Edited March 29, 2012 by Alex/AT

[kaN5300]

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

 

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

[vitalyb]

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

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

[Ilya Evseev]

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

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

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

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

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

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

[Alex/AT]

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

 

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

 

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

Edited March 30, 2012 by Alex/AT

[NiTr0]

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

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

[vitalyb]

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

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

Edited March 31, 2012 by vitalyb

[Alex/AT]

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

Edited March 31, 2012 by Alex/AT

[alks]

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

[Alex/AT]

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

 

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

Edited April 2, 2012 by Alex/AT

[DenKZ]

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

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

С чего это?

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

Edited April 1, 2012 by DenKZ

[alks]

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

 

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

[Alex/AT]

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

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 April 2, 2012 by Alex/AT