kaN5300 Опубликовано 29 марта, 2012 · Жалоба Присматриваем юнипроцессорную конфигурацию для очередного сервера доступа. Заинтересовала технология Data Direct I/O в обновленных ксеонах Пишут что за счет прямой работы NIC с кэшем производительность удастся поднять на 10-20 процентов. При этом никакой дополнительной поддержки со стороны сетевухи или софта не требуется. Про сроки появления на прилавках серии 1ХХХ ничего не известно в то время как на ЯМ уже масса предложений по сериям 2XXX. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edgars Опубликовано 29 марта, 2012 · Жалоба Не надо тут пугать людей такими страшными картинками, а то сейчас все от ужоса вырвут все волосы изподмышек. Как же мы всё это время работали с таким хауном?! :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 29 марта, 2012 (изменено) · Жалоба На самом деле есть какой-то маркетинговый нюанс в этой диаграмме, поскольку на тех же igb всё уже давно memory-mapped. Изменено 29 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 29 марта, 2012 · Жалоба На самом деле есть какой-то маркетинговый нюанс в этой диаграмме, поскольку на тех же igb всё уже давно memory-mapped. Маркетинг здесь замешан по-любому. Жаль нет сравнительного тестирования для загруженных маршрутизаторов в открытом доступе. У нас на топовом Core i7 при 50% idle на всех ядрах наблюдается подозрительный рост load average. При этом весь тюнинг igb необходимый сделан, очереди грамотно раскидываются по ядрам и т.д. Где-то явно образуется bottleneck и это не nic и не cpu. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 29 марта, 2012 · Жалоба Получается, что 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 напрямую забирает? А почему сразу не сделали в обе стороны? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 29 марта, 2012 · Жалоба Пишут что за счет прямой работы NIC с кэшем производительность удастся поднять на 10-20 процентов. Судя по картинке и названию ссылки, поднимется только скорость обмена данными между сетевой картой и процессором. Внутри процессора+ОЗУ и внутри сетевой всё останется по-прежнему. Если у Вас не голый роутинг, то эти 20 процентов на общем фоне будут слабо заметны, скорее всего. Поэтому используйте то, что есть в продаже, и не парьтесь. Всё равно на новые модели Ксеонов цена всегда задрана до безобразия. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 30 марта, 2012 (изменено) · Жалоба Возможно суть технологии в том, что устройства с MMIO наконец-то научили управлять линейками кеша процессора. Т.е. memory-mapped - это хорошо, но это на практике некешируемые регионы. Если они стали кешируемыми - вдвойне замечательно, но схема от интела выше всё равно отдает неадекватизмом, системная память при MMIO никаким боком не участвует :) Поэтому сий вариант не рассматриваем всерьез. Либо более вероятный второй вариант - это отправка данных через кеш (когда буфер на отправку выделяется не в системной памяти, а в кеше). Теоретически чем-то лучше, чем стандартный SG с обращением к памяти через "DMA"/"BM", но фокус в том, что кеш в данном случае может быть только shared (очевидно, L3), поскольку аллокация буфера может начаться на одном ядре, и завершиться отправкой на другом (в отдельных случаях с прибивкой интов к ядрам), а L3 тоже не сильно эффективен. Ну и zero-copy с такими буферами получится только в пределах разве что именно тупого роутинга, когда фрейм в буфере не меняет длины, если идёт хоть какая-то инкапсуляция/декапсуляция, к примеру PPPoE, или просто передача приложению - в первом случае всё равно уже нужна поддержка SG, во втором - работа с системной памятью. Кто-нибудь интересовался, SG (scatter-gather, в данном случае больше интересует именно gather, возможность "сборки" фрейма из кусочков, разрозненных по адресам в буферах) в данной технологии есть, или пока нет никакой дополнительной информации? Изменено 30 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 31 марта, 2012 · Жалоба Возможно суть технологии в том, что устройства с MMIO наконец-то научили управлять линейками кеша процессора Судя со скринов, DMA научили кешироваться, в л3 по ходу... Сомневаюсь, что все именно так как на скрине (выделение памяти исключительно в кеше), более вероятно, что ИКП стал кешировать все запросы к памяти, а не только запросы процессорных ядер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 31 марта, 2012 (изменено) · Жалоба Кто-нибудь интересовался, SG (scatter-gather, в данном случае больше интересует именно gather, возможность "сборки" фрейма из кусочков, разрозненных по адресам в буферах) в данной технологии есть, или пока нет никакой дополнительной информации? По идее SG исключительно фича сетевой карты - сможет ли собрать/разобрать фрейм по кускам или нет, и если никакой дополнительной поддержки действительно не нужно, думаю, должно работать. Изменено 31 марта, 2012 пользователем vitalyb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 31 марта, 2012 (изменено) · Жалоба Одно дело SG из системной памяти, другое дело - буфер в линейках кеша... Вот в том и вопрос - сможет оно переупорядочить данные из линейки кеша, или придётся софту собирать в этом буфере линейный фрейм. Изменено 31 марта, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 1 апреля, 2012 · Жалоба Объясните нубу - для NAT прирост будет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 1 апреля, 2012 (изменено) · Жалоба Для больших инсталляций скорее всего нет - там узкое место в поддержании таблиц сессий. А вот там, где клиентов мало, а трафика много - может быть. Ну и да - прирост будет не раньше, чем под это дело допилят драйверы. Изменено 2 апреля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DenKZ Опубликовано 1 апреля, 2012 (изменено) · Жалоба Поэтому используйте то, что есть в продаже, и не парьтесь. Всё равно на новые модели Ксеонов цена всегда задрана до безобразия. С чего это? Цена на предыдущий E5620 такая-же как и на E5-2620... - $20 разницы не в счет... Изменено 1 апреля, 2012 пользователем DenKZ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 2 апреля, 2012 · Жалоба Для больших инсталляций скорее всего нет - там узкое место в поддержании таблиц сессий. А можно поподробнее этот момент осветить? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 2 апреля, 2012 (изменено) · Жалоба Да а чего его освещать: 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, в последние ядра не смотрел. Изменено 2 апреля, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...