Перейти к содержимому
Калькуляторы

PPPoE сервер на 82599 под линукс Кто-то делал?

Всем привет.

 

Решил создать отдельную тему, производную от этой: http://forum.nag.ru/forum/index.php?showtopic=91313

 

Суть проблемы: карта на 82599 чипе не распределяет по очередям трафик, если он PPPoE. Я проводил синтетические тесты, но на реальных тестах должно быть тоже самое. Трафик может быть с разных IP, VLAN, MAC и всего остального - это роли не играет - все пакеты попадают в первую очередь. Ядро, драйвера свежие.

 

Есть ли такие на форуме, кто собирал такой сервер с такой картой? Была ли такая же проблема? Поделитесь опытом, пожалуйста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это аппаратное ограничение, об этом написано в документации.

Используйте RPS.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это аппаратное ограничение, об этом написано в документации.

Используйте RPS.

 

Ну я с вами не согласен насчет того что, что это написано в документации. Я, например, чтобы докопаться до истины потратил достаточно не мало времени. Прочитав документацию и разобрав её до битов пакета такой вывод можно сделать, да. Было бы там предложение, что "чуваки, любое туннелирование у нас по очередям не балансится" - вопросов бы вообще не было.

 

Более того, вы первый, кто говорит мне о том, что это есть в документации.

 

На предмет RPS посмотрю, спасибо.

 

Ну а вы или NiTr0 делали сабж? С RPS всё работает как надо?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RPS он же софтовый, ему не сильно принципиально какая карта

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RPS он же софтовый, ему не сильно принципиально какая карта

 

Понимаете, тут есть тонкий момент. PPPoE трафик без проблем балансится на 82579. Для меня было совершенно неожиданно то, что на 82599, который более продвинутый, типа, это нерешаемая задача ( RPS это уже из арсенала ОС а не самой карты ).

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я сабж не делал.

Интересовался только пару лет назад, уже на закате PPPoE. Тогда удивился такому поведению, поискал, нашел замечание об этом где-то в документации и успокоился.

Сейчас у меня PPPoE нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Понимаете, тут есть тонкий момент. PPPoE трафик без проблем балансится на 82579. Для меня было совершенно неожиданно то, что на 82599, который более продвинутый, типа, это нерешаемая задача ( RPS это уже из арсенала ОС а не самой карты ).

 

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

На 82576(ET) оно так же не балансится, падая в 1 очередь. Точно на 579 есть очереди и они работают с pppoe?

 

RPS пробовал на стенде, раскидывает абсолютно любой трафик в любой ситуации(оно там похоже per-flow работает). До боевых серверов дело не дошло, начали убирать pppoe :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Можно попробовать ntuple фильтры и по макам разбалансировать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На 82576(ET) оно так же не балансится, падая в 1 очередь. Точно на 579 есть очереди и они работают с pppoe?

 

RPS пробовал на стенде, раскидывает абсолютно любой трафик в любой ситуации(оно там похоже per-flow работает). До боевых серверов дело не дошло, начали убирать pppoe :)

 

Есть и работают на 82579 - сервера в продакшене стоят - всё отлично. Работает из коробки без RPS и вообще без бубнов. Ядро 2.6.27.

 

RPS существенно на тестах производительность не роняет? Все же это происходит на уровне софта, а не железки. Пусть и в пространстве ядра.

 

Можно попробовать ntuple фильтры и по макам разбалансировать.

 

Нельзя, потому что ntuple пропускает тунелированные пакеты, это первое, а во-вторых, никто, ни ntuple, ни Flow Director не умеют L2. Можно только через VF, которые у меня не заработали. Впрочем, я не представляю как это сделать на продакшене без костылинга.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я делал все проще , сколько ядер столько портов (сетевух). Обычно у меня брасы с 4 ядрами и две 2-х портовые карты 82599/I350. Вообщем делаю по одной очереди и получается каждая очередь на свое ядро. 4 ядра -4 порта. По два порта в bond , на вход и на выход

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Включите RPS без RFS, потери от него невелики, а пользы достаточно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я делал все проще , сколько ядер столько портов (сетевух). Обычно у меня брасы с 4 ядрами и две 2-х портовые карты 82599/I350. Вообщем делаю по одной очереди и получается каждая очередь на свое ядро. 4 ядра -4 порта. По два порта в bond , на вход и на выход

 

Ну это не проще, а странно. Зачем покупать сетевуху за много денег, которая умеет 128 очередей, если можно купить риалтек? Там тоже одна очередь на порт.

 

По теме: в мейлистах e1000-devel признались, что надо юзать RPS и спихнули вину за кривой RSS на майкрософт, по спецификации которого это якобы сделано.

 

Вообщем буду пробовать RPS, отпишусь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну это не проще, а странно. Зачем покупать сетевуху за много денег, которая умеет 128 очередей, если можно купить риалтек? Там тоже одна очередь на порт.

Кроме кол-ва очередей есть такие важные параметры как размер rx/tx ring

 

И вообще что-то не видно на рынке 2x10G карт за 3 копейки от реалтека, в отличии от GE-карт

 

И к тому же я сомневаюсь, что кроме как в ex-USSR и некоторых других отсталых странах кто-то использует самосбор под брасы, т.е. проще говоря нет реального бизнес-кейса на нормальную поддержку L2-балансировку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кроме кол-ва очередей есть такие важные параметры как размер rx/tx ring

 

И вообще что-то не видно на рынке 2x10G карт за 3 копейки от реалтека, в отличии от GE-карт

 

И к тому же я сомневаюсь, что кроме как в ex-USSR и некоторых других отсталых странах кто-то использует самосбор под брасы, т.е. проще говоря нет реального бизнес-кейса на нормальную поддержку L2-балансировку.

 

Речь о том, что делать специально кол-во портов = кол-во процессоров - это странно. Насчет того что нет 10Г карт дешевых, ну так это же bleeding edge. Еще немного времени пройдет и появятся. Интел как раз к этому времени сделает 100Г.

 

Насчет реального кейса - не соглашусь. Не забывайте, что сервера разные бывают. Самосбор, конечно, никто не ставит, но это не значит, что в брендовых серверах стоить что-то не 82599. И эти сервера от кошек или джуниперов по поддержке железа ничем не отличаются. А софт свой, например. Чем не юзкейс?

 

Другой вопрос распостраненность PPPoE и других туннелей, но тут возникает вопрос к разработчикам чипа тогда: зачем было городить такой огород фильтров, если вы не умеете фильтровать L2. Вернее они умеют, но только через VF ( как юзать в продакшене не ясно ). А ntuple фильтры и Flow director, которые L3/L4 - умеют только UDP и только по 4ем полям. У L2 смещения не меняются и вообще всё хорошо, хешируй куда хочешь.

 

Внимание ответ: потому что по спецификации MS в хеши RSS не входят заголовки L2, а до L3 мы добраться не можем, ибо туннель.

 

Ну то есть в этом свете, для меня "нет реальных юзкейсов для балансировки L2" выглядит как попытка выгородить это кривое поделие. Случай может и вырожденный, но это не значит что он выдуман и невозможен в бизнесе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel

Под самосбором я имел ввиду вообще софт-брасы на linux/freebsd.

 

Всё-таки сервера обычно(за исключением ex-USSR ISPs) используются как сервисные платформы(ну т.е. веб-сервера и т.п.), где l2 балансировка не нужна ибо на них нет pppoe и там всё отлично балансируется по L3/L4.

 

Если говорить про решения типа Cisco ASA, которая по железу обычный HP-сервер, то в них тоже нет pppoe

 

Я не выгораживаю Intel, а просто говорю, что реальных бизнес-кейсов на то что вы хотите нет

 

С 40/100G да, поинтереснее будет, там явно одного ядра CPU под pppoe не хватит

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

никто, ни ntuple, ни Flow Director не умеют L2

Действительно, смутил доступный параметр в ethtool...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я вас пытаюсь понять, но не могу. А что, PPPoE брасы у ex-USSR ISP - это не бизнес-кейс?

 

Ну и чтобы 2 раза не вставать: c RPS всё работает как надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А что, PPPoE брасы у ex-USSR ISP - это не бизнес-кейс?

 

Ну сколько это карточек(именно под pppoe)? 1000-2000 в год? Эта карточка стоит около 500$, итого речь идёт всего где-то около 1млн $. За вычетом посредников и себестоимости вообще смешные деньги получаются

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я не думаю, что рынок этих карт вообще велик, поэтому мне сложно судить 1000-2000 в год это много или мало. Я лишь пытался указать на тот факт, что юзкейс есть. И чтобы его сделать возможным нужно всего лишь добавить еще одну функцию парсинга в чип. Я не думаю, что эта задача сложна и стоит больше, чем возможная выгода.

 

На 82579 же сделали и не обломались.

 

Мне вообще кажется, что это больше ошибка и недочет, нежели специальное исключение функции по каким-то соображениям. То есть банальная недоработка. Иначе в доке было бы написано: юзайте RPS. Тем временем в доке эти выводы можно сделать только косвенным путем потратив уйму времени, как это сделал я.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я не думаю, что рынок этих карт вообще велик

т.е вы думаете что все сервисы всё ещё живут на 1GE-картах? да многие продожают юзать 1г и агрегировать их, например ggc, но всё же очень много широкополосных сервисов переходит на десятки и это их рынок. да и всякие приват облака тоже щас больше на десятках

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кому-то и 10ок мало, контентщики уже 40ки вон пробуют :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и чтобы 2 раза не вставать: c RPS всё работает как надо.

Что самое прелестное - оно и на 82574(L) так работает, хотя там оверхеда побольше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

т.е вы думаете что все сервисы всё ещё живут на 1GE-картах? да многие продожают юзать 1г и агрегировать их, например ggc, но всё же очень много широкополосных сервисов переходит на десятки и это их рынок. да и всякие приват облака тоже щас больше на десятках

 

Конечно нет. Я думаю, что достаточно большое количество сервисов работает на железках типа кошек и джунов, где свое железо и есть 40 и 100Г. Это я про телеком. Про контент ситуация похуже - там надо действительно покупать карты, но насколько велик спрос - не известно. Говорю к тому, что оценить размер рынка 10Г карт интела - сложно. А понять насколько велика доля карт для PPPoE серверов - еще сложнее. С другой стороны, если всё работает с RPS Интел может разрулить ситуацию просто апдейтом к документации. Что тоже не плохо, кстати. Однако RPS и RFS ( чтобы работало как RSS или как ntuple filter ) даст оверхед, то есть однозначно хуже хардварного решения.

 

Что самое прелестное - оно и на 82574(L) так работает, хотя там оверхеда побольше.

 

Ну оно для таких карт и было сделано. Если есть очереди и RSS работает нормально, то RPS не нужен. А так он и на риалтеках работает. Другой вопрос, что не все драйверах можно удобно крутить настройки. У интела можно всё гибко отрегулировать и упереться в процессоры или порты. В других картах, не предназначеных для этого можно начать ловить переполнение PHY или наоброт прерывание на каждый пакет дающим чудовищный оверхед.

 

И, кстати, с RPS не плохо бы включать RFS, потому что без него будет большое количество cache_miss и в итоге Ксеоны превратятся в какие-нибудь дуал коры с малым кешем, если задача не тупой пакет форвардинг.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И, кстати, с RPS не плохо бы включать RFS, потому что без него будет большое количество cache_miss и в итоге Ксеоны превратятся в какие-нибудь дуал коры с малым кешем, если задача не тупой пакет форвардинг.

RFS работает только для локальных сокетов, т.е. на брасах лишь добавит оверхеда от поддержания второй таблицы, использоваться она не будет. Единственное, что оно сделает - это локализует пакеты PADI/PADO/PPTP CTL, идущие в юзерспейс, что в рамках BRAS чуть менее, чем бесполезно.

Ещё есть XPS, но толку от него при практических тестах для BRAS также оказывается чуть менее, чем 0. Видимо, по сходной с RFS причине - действует только для локальных сокетов.

Причём всё сказанное едино вне зависимости от карточки (из списка попробованного: e1000, e1000e, igb, tg3, bnx2).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.