BGP 10G Soft Router Своими руками v1.0

[Fanat_non_root 88]

В том, что ТКАМа нету? или в отсутсвии асика?

 

Это как бы одно и тоже

 

"асик" - это специализированный процессор с параллельно-конвейерной архитектурой реализованный на плис, на таких же плис, как ступень конвейера имплементируется TCAM.

Имелась ввиду не сама-по себе ассоциативная память, а скорость её работы.

Да и асики разные бывают, по сути-то асик это проц заточенный под одну, вполне конкретную задачу, т.е. DSP тоже асики.

[NiTr0 583]

1. Имелось ввиду различие между новыми оптеронами и старыми феномами

2. Вопрос весьма спорный, я получал сведения, что новые оптероны существенно быстрее работают с памятью.

Новые оптероны имеют те же ядра, что и FX8150 десктопный. Линейка с piledriver ядрами еще массово не продается, да и там скорее эволюция, чем революция - выше производительность на ядро, но хуже с латентностью (незначительно, в пределах погрешности). И латентность памяти и кешей у них выше, чем у феномов.

Пропускная способность конечно может быть и выше, за счет 4-канальной памяти у 62xx - но это все равно NUMA в одном корпусе, склейка из 2 ядер, и с все теми же большими задержками, от того не все так однозначно.

[Fanat_non_root 88]

CAM используется для L2, снятия и постановки тегов вланов, поиска маков...

TCAM используется для ip маршрутизации, acl...

Думаю стоит расказать об это экстриму, который в своих х480 использует один и тот же ТКАМ как для маршрутов, так и для маков.

[Fanat_non_root 88]

Новые оптероны имеют те же ядра, что и FX8150 десктопный. Линейка с piledriver ядрами еще массово не продается, да и там скорее эволюция, чем революция - выше производительность на ядро, но хуже с латентностью (незначительно, в пределах погрешности). И латентность памяти и кешей у них выше, чем у феномов.

Пропускная способность конечно может быть и выше, за счет 4-канальной памяти у 62xx - но это все равно NUMA в одном корпусе, склейка из 2 ядер, и с все теми же большими задержками, от того не все так однозначно.

Сложно сказать, я пилидрайвер (именно эту архитектуру я имел ввиду под "новыми оптеронами") я еще не щупал, но вот такие вот слух ходют, что с памятью они быстрее зеонов серии Е5 работают.

[NEP 217]

Думаю стоит расказать об это экстриму, который в своих х480 использует один и тот же ТКАМ как для маршрутов, так и для маков.

 

TCAM может эффективно решить обе задачи. И что? ntil привел реализацию референсного cam от actel, так что по вашему Екстрим использует это УГ?

[Fanat_non_root 88]

Думаю стоит расказать об это экстриму, который в своих х480 использует один и тот же ТКАМ как для маршрутов, так и для маков.

 

TCAM может эффективно решить обе задачи. И что? ntil привел реализацию референсного cam от actel, так что по вашему Екстрим использует это УГ?

Ну если учесть, какие возможности заявляет экстрим для 480 - врят ли

[KaYot 3 605]

Новые оптероны имеют те же ядра, что и FX8150 десктопный. Линейка с piledriver ядрами еще массово не продается, да и там скорее эволюция, чем революция - выше производительность на ядро, но хуже с латентностью (незначительно, в пределах погрешности). И латентность памяти и кешей у них выше, чем у феномов.

Пропускная способность конечно может быть и выше, за счет 4-канальной памяти у 62xx - но это все равно NUMA в одном корпусе, склейка из 2 ядер, и с все теми же большими задержками, от того не все так однозначно.

Сложно сказать, я пилидрайвер (именно эту архитектуру я имел ввиду под "новыми оптеронами") я еще не щупал, но вот такие вот слух ходют, что с памятью они быстрее зеонов серии Е5 работают.

У меня домашняя машина на этом самом пайлдрайвере(trinity FM2), с памятью там все то же что у атлонов стареньких.

[Fanat_non_root 88]

Спасибо за отзыв. Жаль, так хотелось чуда

Ну интел, так интел.

[ntil 57]

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии )

 

Вводная

Протокол - IPv4

количество маршрутов - 1М

Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин.

Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию.

(тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно).

Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам.

 

 

как это работает:

по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска.

далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам.

 

В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ.

т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС

но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек.

соответственно 1200\16= 75 МППС

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

 

восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет).

 

и тут еще много можно оптимизировать, например с соотношением количества бит в таблице индексов и оставшихся бит для поиска, самим алгоритмом поиска, представлением данных.

 

Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

[NiTr0 583]

Сложно сказать, я пилидрайвер (именно эту архитектуру я имел ввиду под "новыми оптеронами") я еще не щупал, но вот такие вот слух ходют, что с памятью они быстрее зеонов серии Е5 работают.

Посмотрите обзоры FX8350. Результаты не лучше чем 8150-го. Да собссно никто и не заявлял чуда по части подсистемы памяти. +10% ipc на равных тактовых - да, наблюдается, меньшее потребление - наблюдается, на этом все и оканчивается.

[NEP 217]

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии )

 

Вводная

Протокол - IPv4

количество маршрутов - 1М

Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин.

Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию.

(тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно).

Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам.

 

 

как это работает:

по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска.

далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам.

 

В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ.

т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС

но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек.

соответственно 1200\16= 75 МППС

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

 

восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет).

 

и тут еще много можно оптимизировать, например с соотношением количества бит в таблице индексов и оставшихся бит для поиска, самим алгоритмом поиска, представлением данных.

 

Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

 

Бред.

 

Какой DDR2? Вы несете чушь! Вы вообще понимаете отличие DDR2 (SDRAM) памяти от SRAM? Понимаете что такое латентность? Вы понимаете, что латентность DDR может достигать сотен тактов спецпроцессора, а SRAM работает на частоте процессора и не имеет латентности по определению? И при произвольном доступе вот это 200\16=12,5 МППС вообще БРЕД в квадрате. Это можете поделить смело на 50, а лучше на 100 и получить свои сопливые 125 КППС и это ТЕОРЕТИЧЕСКИЙ потолок.

[ntil 57]

DDR2 SRAM !!статическая память!!. прочитайте внимательно! у меня ща на девборде припаяна. я прекрасно знаю отличия. у нее латентности (в тактах) нет, DDR2 просто говорит о стробировании сигнала на шине по обоим фронтам импульсов.

 

вовторых Ваши аргументы не обоснованы, т.к. не содержат соответствующей аргументации, только визги "БРЕД" чуствую что говорю не с технарем а с гумманитарием.

 

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

[ntil 57]

Это можете поделить смело на 50, а лучше на 100 и получить свои сопливые 125 КППС и это ТЕОРЕТИЧЕСКИЙ потолок.

Аргументируйте, почему именно 50, 100 а не 1221 например?

[martin 170]

у меня стоят новые 8150 и 8350 - могу с уверенность сказать что даже до i7 им далеко, неговоря уже о Xeon.

Так что в роутинге и перестройке таблицы БГП Интел до сих пор рулит.

[pavlabor 1 914]

ну давайте проведем численную оценку IP LookUp Engine (я тут специально не буду употреблять САМ для того, чтобы не придирались к терминологии )

 

Вводная

Протокол - IPv4

количество маршрутов - 1М

Маршруты скомпилированы (оптимизированы) в однозначную заранее сортированую таблицу-структуру, которая затем загружается софтом (демоном BGP например) в лукап энжин.

Фактически во внешнем ОЗУ ПЛИС таблица представлена в однозначном виде , подсетями не короче /16 , упорядочеными по возростанию.

(тут есть еще ньюансы с масками и more specific subnets, но я это опущу, т.к. долго буду рассказывать, считае что у нас такого нет - т.е. все однозначно).

Во внутреннем ОЗУ ПЛИС находится табличка индексов, чтобы избежать бинарного поиска по первым 16 битам.

 

 

как это работает:

по первым двум байтам (16 бит) - фактически они адрес во внутреннем быстром ОЗУ ПЛИС - считывается указатель на точку начала поиска и начальное значение счетчика бинарного поиска.

далее аппаратно осуществляется бинарный поиск необходимого значения по оставшимся 16 битам.

 

В этом сценарии узким местом является внешнее ОЗУ ПЛИС. так для поиска по оставшимся 16 битам необходимо произвести в наихудшем случае (максимально) 16 чтений из внешнего ОЗУ.

т.е. при использрвании SRAM 200MHz мы получим 200\16=12,5 МППС

но! мы можем например использовать 600 МГц DDR2 SRAM, что даст нам 1200 М чтений в сек.

соответственно 1200\16= 75 МППС

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

 

восемь банков памяти на 1й плис дают 600 МППС, что уже значительно. это 600МППС х 8бит х 64Байт ~ 307 Гбит 64байтными пакетами (с учетоп заголовков эзернет).

 

и тут еще много можно оптимизировать, например с соотношением количества бит в таблице индексов и оставшихся бит для поиска, самим алгоритмом поиска, представлением данных.

 

Кстати интересно будет еще посчитать для SDRAM внешней, хотя имхо тухлый номер

А это где так работает БЖП?

Помоему это время давно ушло в историю.

[ntil 57]

а причем тут бгп. ?

бгп он чисто софтварный , как правило. его дело наполнять таблицу маршрутов (внешнюю по отношению к нему) в циске так, в линукск так. откройте исходники квагги и посмотрите.

 

здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

[pavlabor 1 914]

а причем тут бгп. ?

бгп он чисто софтварный , как правило. его дело наполнять таблицу маршрутов (внешнюю по отношению к нему) в циске так, в линукск так. откройте исходники квагги и посмотрите.

 

здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

БЖП это протокол, а в софтовом роутере таблицу наполняет квага(например),

а аппаратный поиск, давно так не делается,

там проц тогда нужен, на соточной мыльнице, минимум 3-6 гигагерц, чтобы перелопатить поток с простой раскладкой пакетов по портам на уровне маков.

 

Сегодня уже и софтовые роутеры так не работают.

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

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

 

Потому и говорят - таблицу наполняет.

[ntil 57]

а причем тут бгп. ?

бгп он чисто софтварный , как правило. его дело наполнять таблицу маршрутов (внешнюю по отношению к нему) в циске так, в линукск так. откройте исходники квагги и посмотрите.

 

здесь описан метод аппаратного поиска в большой таблице маршрутов, которую может заполнять БГП, ОСПФ, или рабыня филипинка, а то и все сразу.

БЖП это протокол, а в софтовом роутере таблицу наполняет квага(например),

а аппаратный поиск, давно так не делается,

там проц тогда нужен, на соточной мыльнице, минимум 3-6 гигагерц, чтобы перелопатить поток с простой раскладкой пакетов по портам на уровне маков.

 

Сегодня уже и софтовые роутеры так не работают.

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

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

 

Потому и говорят - таблицу наполняет.

Пожалуйста, прочитайте мои предыдущие посты. я какраз и сетую за хадверный роутер на ПЛИС, описывал и отстаивал методику расчета производительности движка выборки маршрута из уже для него, ХАРДВАРНОГО, специально оптимизированной для аппаратного разбора таблицы..

БГП там может хоть на АРМ крутится, не о нем реч.

[pavlabor 1 914]

Я сетую за софтовый.

Простой пример,

если у прова один маршрут, и он получил фюв, то хард всервно должен отчехлить под задачу матрицу по полной программе,

а софтовый, может заменить все хозяйство дефаултом.

 

Хардовый роутер, это винда, разрешено то что разрешено, кнопки нет - будь здоров.

софтовый это фря, нет кнопки нарисуем.

По производительности, хардовый обходит софтовый, потому как у него логический автомат заточен под решение распространненой задачи,

шаг в сторону, докупаем плату шейпа или ната, за тисячи уе.

Если решать на софтовом аналогические задачи, то это на порядоу дешевле.

 

И если сегодня какойто производитель выпустит нормальную сетевую, которую интел уже сделал минимум пять лет назад,

то цыски накроются медным тазом.

 

Вот сижу и думаю, может сделать самому такую карточку, и посмотреть на реакцию интела.

[NiTr0 583]

если у прова один маршрут, и он получил фюв, то хард всервно должен отчехлить под задачу матрицу по полной программе,

а софтовый, может заменить все хозяйство дефаултом.

Кто помешает аппаратному роутеру забить один дефолт в ткам вместо горки роутов? Как собссно умеют те же 3550, которые кое у кого стоят вместо бордюров.

И какая принципиальная разница, куда control plane пихает роуты - в таблицу ядра, или в ткам?

[pavlabor 1 914]

Таблица ядра(коммутационное поле) это логический автомат,

там понятие "обработка", арифметика отсутствует как класс,

он работает согласно тактовой частоте,

у него нет понятия нагрузки и скорость обработки зависит от скорости работы полупроводниковых переходов,

а ткам, это память, которую юзает проц, который занимается арифметикой, пыхтит, греется и пугает всех 100%-ной загрузкой.

 

Пример коммутационного поля

http://www.intuit.ru/department/network/telenetdev/1/

 

[NiTr0 583]

а ткам, это память, которую юзает проц

C какой такой радости? Как раз в ткаме и живет таблица маршрутизации. И наполняется она контрол плейном, на его усмотрение. Контрол плейн может и один роут туда вбить, дефолт, вместо фулл вью, а фулл вью при этом держать только в контрол плейне и анонсить соседям оттуда же. Никто собссно не запрещает.

[ntil 57]

где-то так.

блин, как лень писать ...

вот лучше гляньте Архитектура Cisco Catalyst 6500.pdf

[pavlabor 1 914]

а ткам, это память, которую юзает проц

C какой такой радости? Как раз в ткаме и живет таблица маршрутизации. И наполняется она контрол плейном, на его усмотрение. Контрол плейн может и один роут туда вбить, дефолт, вместо фулл вью, а фулл вью при этом держать только в контрол плейне и анонсить соседям оттуда же. Никто собссно не запрещает.

 

Есть понятие память,

есть понятие что с нее можно слепить,

есть понятие софтовая коммутационная матрица,

и есть понятие хранение таблицы в памяти.

Если память использовать как хранилище в котором находится таблица маршрутизации,

то нужен проц, который будет дергать регистры и сравнивать с ип адресом,

на эту задачу уйдет вагон машинных циклов.

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

то нужен один машинный цикл, для получения результата.

 

Вот ответ, мегапризводительности.

Хардовый роутер отправляет пакет, без участия проца, за один такт кварца.

Софтовый роутер, тратит несколько машинных циклов для решения аналогичной проблемы,

алгоритм который описал ntil.

Но сегодня, на таких серьезных решениях не используют методы пузырьковых сортировок,

сегодня на таких задачах используют метод матриц прямого доступа.

Цыфры ип адреса, это не значения а координаты точки выхода,

и если там 0, пакет дропится, если 1, пакет отправляется.

Это мгновенная операция и даже на софтовом уровне обойдется парой машинных циклов.

 

То что сейчас подняли в данном топике, это оптимизация работы сетевой карты,

на предмет парализации потоков, это вариант масштабирования,

но не оптимизации решения задачи, продавливание лбом.

Вариант где замахнулись на 100гиг - использование процессора видеокарты кубо, проца производительней чем риск процессора.

Тоже продавливание задачи лбом.

Третий вариант от интела, это самый перспективный вариант, который они положили пол сукно, до хороших времен.

Он заключается в сращивании аппаратного решения и софтового...

Сегодня, на базе наличного парка микросхем, можно самому сделать решения с паяльником, на коленке,

и такой роутер будет дешевле и производительней на порядок аппаратного.

 

Вот только никак не разродятся.

 

Отсюда, софтовый роутер, уделает аппаратный.

[NiTr0 583]

а ткам, это память, которую юзает проц

C какой такой радости? Как раз в ткаме и живет таблица маршрутизации. И наполняется она контрол плейном, на его усмотрение. Контрол плейн может и один роут туда вбить, дефолт, вместо фулл вью, а фулл вью при этом держать только в контрол плейне и анонсить соседям оттуда же. Никто собссно не запрещает.

 

Есть понятие память,

есть понятие что с нее можно слепить,

есть понятие софтовая коммутационная матрица,

и есть понятие хранение таблицы в памяти.

Ознакомьтесь лучше, что такое ткам, и в чем его отличие от памяти контрол-плейна...