Dark_Angel Опубликовано 22 мая, 2014 · Жалоба Странно в документации про то что соединения должны быть локальными ничего не говорится. Зато красиво рассказывается, как там анализируются хедеры, как в RSS. На каком ядре вы проводили тесты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 26 мая, 2014 · Жалоба Странно в документации про то что соединения должны быть локальными ничего не говорится. Зато красиво рассказывается, как там анализируются хедеры, как в RSS. Как это не написано? https://www.kernel.org/doc/Documentation/networking/scaling.txt While RPS steers packets solely based on hash, and thus generally provides good load distribution, it does not take into account application locality. This is accomplished by Receive Flow Steering (RFS). The goal of RFS is to increase datacache hitrate by steering kernel processing of packets to the CPU where the application thread consuming the packet is running. Ну и если в код ядра поглядеть - RFS по сути начинается уже в UDP/TCP/whatever частях стека, которые при роутинге не затрагиваются. Тестировал - на специфичном центосовском 2.6.32 с бэкпортом существенных патчей в т.ч. на тему RPS/RFS/XPS/... из мейнстрима до октября 2013 включительно. Сейчас у меня бета-ядро уже с бэкпортом до марта 2014, однако на оном тесты еще не гонял. Что-то подсказывает, что раз за январь-октябрь 2013 ничего в этом вопросе не изменилось - то не изменится и сейчас. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 28 мая, 2014 · Жалоба А почему не написать об этом фиче/баге в Intel? Прочитал всю тему крайне внимательно, но ни единого упоминания обращения к производителю не нашел. Вдруг там три строки фикса :) У нас так с бродкомом было, когда Q in Q не работал на tg драйвере. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 29 мая, 2014 (изменено) · Жалоба Я писал в мейлисты и чуваки мне отвечали с мылами @intel.com. Писали всякий бред про VMDq и другой неюзабельный, для текущей задачи, хлам. Потом пришел Эмиль Тантилов ( тоже @intel.com ) и отписался в конце-концов про RPS, после чего я написал, что не плохо бы в доке заапдейтить. После чего молчание. Вот тред кому интересно: http://sourceforge.net/p/e1000/mailman/e1000-devel/thread/27454542.6692.1400481996366.JavaMail.javamailuser%40localhost/#msg32353886 На самом деле у Интела нормальные доки и комьюнити, пусть и ответили позже чем здесь, так что я думаю, что апдейт будет в следующих ревизиях доки. А фикса в пару строк не будет, потому что выпиливать SRC IP, DST IP из туннелированного пакета - это накладно. Тут надо хешировать по маку, а у них юзается MSFT RSS, которая не умеет хешировать маки. И я не понимаю зачем было делать чтобы тунеллированные пакеты, скармливались RSS, если очевидно, что в тунеле смещения у SRC IP и DST IP будут другими для любой инкапсуляции. То есть по факту нерабочая логика в доке и в железке. В итоге при юзании RPS будет вымываться кеш процессора, т.к. пакеты из одного потока будут попадать на разные процессоры. Думаю оверхед такого решения будет значительным. Пока оценить не могу, т.к. проводил только синтетические тесты, а на них не видно. Изменено 29 мая, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 25 ноября, 2014 · Жалоба Апну, пожалуй, тему. Кто подскажет как сейчас обстоят дела с PPPoE на 82576? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 25 ноября, 2014 · Жалоба Кто подскажет как сейчас обстоят дела с PPPoE на 82576? примерно так - одно ядро нормального CPU прожёвывает один порт GE с типовым bytes_per_packet=900-1000, поэтому раскидывания прерываний одного порта по разным cpu не требуется Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 25 ноября, 2014 (изменено) · Жалоба А что скажите про карту Intel x710-da4? Если по ней информация, может там добавят балансировку для L2 в случае PPPoE? datasheet на чипсет http://www.intel.com/content/www/us/en/embedded/products/networking/xl710-10-40-controller-datasheet.html Изменено 25 ноября, 2014 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 26 ноября, 2014 · Жалоба Кто подскажет как сейчас обстоят дела с PPPoE на 82576? Страница 287 DS описывает как подсчитывается хеш для пакетов IPv4. Если коротко, то там тот же MSFT RSS. То есть туннелированные пакеты всегда попадают в одну очередь. А что скажите про карту Intel x710-da4? Если по ней информация, может там добавят балансировку для L2 в случае PPPoE? datasheet на чипсет http://www.intel.com...-datasheet.html Страница 670. Та же шляпа - MSFT RSS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 26 ноября, 2014 · Жалоба Кто подскажет как сейчас обстоят дела с PPPoE на 82576? Страница 287 DS описывает как подсчитывается хеш для пакетов IPv4. Если коротко, то там тот же MSFT RSS. То есть туннелированные пакеты всегда попадают в одну очередь. А что скажите про карту Intel x710-da4? Если по ней информация, может там добавят балансировку для L2 в случае PPPoE? datasheet на чипсет http://www.intel.com...-datasheet.html Страница 670. Та же шляпа - MSFT RSS. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 26 ноября, 2014 · Жалоба А может кто подскажет по опыту - есть ли какие-то тонкости в тюнинге системы, имеющей большое кол-во ppp-интерфейсов? кроме самого увеличения интерфейсов вырастают косвенные затраты - например, время выполнения программ типа ip, tc, которые при большом количестве интерфейсов "мешают" друг другу блокировками. сейчас имеем около 3500 pppoe-сессий на одном Xeon E5-2620. при этом в сторону пользователей идет около 220 kpps, поток - менее 2,5 Гб/с Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 26 ноября, 2014 · Жалоба Для ip и tc вообще пофигу количество интерфейсов, если вы конечно не пытаетесь получить их полный список. Там были проблемы с ядрами 2.6.х и немного 3.х и когда интерфейсов было больше 500, начинался какой-то ад дедлоков. После 3.11 всё разрулили и система чувствовала себя ок на синтетике с 10К сессий. Я правда не звал tc, но ip и ifconfig работали очень быстро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 27 ноября, 2014 · Жалоба начинался какой-то ад дедлоков как это выглядит? в логах что-то пишется? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dark_Angel Опубликовано 27 ноября, 2014 (изменено) · Жалоба В логах ничего не пишется, просто у вас в топе висят процессы ядра и новые соединения появляются со скоростью 1 подключение в секунду. Перф топ дает посмотреть на это одним глазком. Прямо скажу - приятного мало. Как будто работаешь в юзер-спейсе. А ну и листинг интерфейсов через тот же ifconfig идет, секунд 10-15, например. Изменено 27 ноября, 2014 пользователем Dark_Angel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 4 декабря, 2014 (изменено) · Жалоба А в случае qinq vlan-per-user , будет балансировка (RSS) или он из-за 2-го тегированиея не увидит ip? Изменено 4 декабря, 2014 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 декабря, 2014 · Жалоба Для ip и tc вообще пофигу количество интерфейсов, если вы конечно не пытаетесь получить их полный список. Там были проблемы с ядрами 2.6.х и немного 3.х и когда интерфейсов было больше 500, начинался какой-то ад дедлоков. После 3.11 всё разрулили и система чувствовала себя ок на синтетике с 10К сессий. Я правда не звал tc, но ip и ifconfig работали очень быстро. Не пофигу совершенно. tc точно при каждом запуске дергает netlink и тянет список ifid - ifname, чтобы делать соответствия. Если интерфейсов много - эта операция похоже или с блокировками, или просто тормозит все подряд (в т.ч. часть функций в ядре). На 5к это уже ОЧЕНЬ тормозило, и я запускал отдельно tc, и делал патч, для передачи ifid напрямую. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 4 декабря, 2014 · Жалоба А в случае qinq vlan-per-user , будет балансировка (RSS) или он из-за 2-го тегированиея не увидит ip? Балансирует. Хрен знает, как - наверное, не смотрит тупо на смещение, а находит IP хедер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
