Ну если используется техника с оффсетами, то TLB будет транслировать только один виртуальный адрес, указатель на начало. Оффсеты что для физических, что для виртуальных адресов при условии непрерывной области памяти должны быть одинаковыми. Так что вымывания tlb кеша быть не должно.
Другое дело что использование huge/super pages будет все же оптимальнее. Единственный плюс данного подхода — не все цпу умеют большие страницы. (См /proc/cpuinfo, где флаг pse — 2М страницы; pdpe1gb — 1G страницы)
Евгений, а вы не сравнивали по производительности netmap с pfring DNA и Intel DPDK?
И второй вопрос, резервирует ли netmap под свои нужды большие страницы (у freebsd вроде superpages называются, аналог hugepages в linux)?
Win8/2012 обещал multipath (если правильно помню) как раз под это. Данные качаются в несколько TCP потоков, и теоретически эти потоки должны размазаться по нескольким линкам.
Вы пропустили ключевое слово hash. Это размер для хеш таблицы коннектов, сами коннекты аллоцируются динамически и добавляются в связные списки, по одному (списку) в каждый бакет хеш таблицы.
Вы бы лучше открыли код, я ж давал выше ссылку в нужное место.
Таблица аллоцируется тут ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(*ip_vs_conn_tab));
внутри функции с говорящим названием ip_vs_conn_init
где ip_vs_conn_tab_size это размер хеш таблицы
static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
ip_vs_conn_tab_size = 1 << ip_vs_conn_tab_bits;
А ip_vs_conn_tab — указатель но голову списка static struct hlist_head *ip_vs_conn_tab __read_mostly;
Убедил? =)
В линуксе это можно посмотреть тут
/sys/devices/system/cpu/cpuX/cache/indexY/Z
где Х — интересующее ядро
Y интересующий кеш (L1 instruction, L1 data, L2, L3)
Z — что конкретно интересует
У меня под рукой, например, xeon X5650, посмотрим как устроен L1 data кеш
cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K — его размер
cat /sys/devices/system/cpu/cpu0/cache/index0/ways_of_associativity
8 — ассоциативность сета
cat /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets
64 — кол-во этих сетов
cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
64 — размер кеш линии
Если речь идет об изменении CONFIG_IP_VS_TAB_BITS, то оно не влияет на максимальное кол-во соединений, на это влияет только кол-во доступной ядру памяти.
Единственный нюанс с которым мы столкнулись — по-умолчанию IPVS готов принимать 4096 одновременных соединений — это 2 бита.
Чтобы балансировщик был готов принимать миллион соединений этот параметр нужно увеличить до 12 битов.
Кол-во соединений ограничено доступной памятью, а 4096 — это размер хеш таблицы для соединений. Не понятно что такое 2 бита. Если вы имеете ввиду этот параметр CONFIG_IP_VS_TAB_BITS
, который задает размер хеш-таблицы размером 2^CONFIG_IP_VS_TAB_BITS, то он и так 12 бит.
Хотя для систем, обрабатывающих большое кол-во соединений, я бы его увеличил. С одной стороны у нас чуть больше будет вымываться кеш, но с другой стороны мы получим сильный прирост в производительности, так как для лукапа соединения в среднем придется итерировать по более коротким связным спискам.
Ну если у Вас где-то используется FR, то легче забить канал, чем завалить RP, ведь максимум порядка 50кппс 64байтных пакетов может влезть в канал. Да, при такой интенсивности RP станет тяжело, но первым исчерпается все же канальная емкость.
>Кстати в сети был легкий фон на OSPF атаку, всякого рода hello пакеты на IP адреса роутеров, т.е. пытались подлезть к СР через NBMA атаку.
Что, простите? Адрес назначения ospf hello пакетов 224.0.0.5, уж никак не «IP адреса роутеров». Из этого следует, что hello не маршрутизируются. Что-то Вы путаете.
2. А почему Рамблер себя не пиарит таким сомнительным способом?
Другое дело что использование huge/super pages будет все же оптимальнее. Единственный плюс данного подхода — не все цпу умеют большие страницы. (См /proc/cpuinfo, где флаг pse — 2М страницы; pdpe1gb — 1G страницы)
И второй вопрос, резервирует ли netmap под свои нужды большие страницы (у freebsd вроде superpages называются, аналог hugepages в linux)?
Далеко не все коммутаторы умеют балансить по L4
Вы бы лучше открыли код, я ж давал выше ссылку в нужное место.
Таблица аллоцируется тут
ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(*ip_vs_conn_tab));
внутри функции с говорящим названием ip_vs_conn_init
где ip_vs_conn_tab_size это размер хеш таблицы
static int ip_vs_conn_tab_bits = CONFIG_IP_VS_TAB_BITS;
ip_vs_conn_tab_size = 1 << ip_vs_conn_tab_bits;
А ip_vs_conn_tab — указатель но голову списка
static struct hlist_head *ip_vs_conn_tab __read_mostly;
Убедил? =)
/sys/devices/system/cpu/cpuX/cache/indexY/Z
где Х — интересующее ядро
Y интересующий кеш (L1 instruction, L1 data, L2, L3)
Z — что конкретно интересует
У меня под рукой, например, xeon X5650, посмотрим как устроен L1 data кеш
cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K — его размер
cat /sys/devices/system/cpu/cpu0/cache/index0/ways_of_associativity
8 — ассоциативность сета
cat /sys/devices/system/cpu/cpu0/cache/index0/number_of_sets
64 — кол-во этих сетов
cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
64 — размер кеш линии
Кол-во соединений ограничено доступной памятью, а 4096 — это размер хеш таблицы для соединений. Не понятно что такое 2 бита. Если вы имеете ввиду этот параметр
CONFIG_IP_VS_TAB_BITS
, который задает размер хеш-таблицы размером 2^CONFIG_IP_VS_TAB_BITS, то он и так 12 бит.
Хотя для систем, обрабатывающих большое кол-во соединений, я бы его увеличил. С одной стороны у нас чуть больше будет вымываться кеш, но с другой стороны мы получим сильный прирост в производительности, так как для лукапа соединения в среднем придется итерировать по более коротким связным спискам.
Что, простите? Адрес назначения ospf hello пакетов 224.0.0.5, уж никак не «IP адреса роутеров». Из этого следует, что hello не маршрутизируются. Что-то Вы путаете.