Увеличиваем производительность сетевых устройств: технология fast path в процессорах Marvell Kirkwood



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

    В процессе разработки устройств для телекома и датакома мы постоянно сталкиваемся с задачами по обеспечению высокой скорости пересылки данных. В рамках этой статьи мы расскажем о том, как их решить. В качестве примера проанализируем работу технологии fast path в процессорах линейки Marvell Kirkwood, измерим параметры сети сети и покажем, каким образом можно повысить производительность различных устройств для маршрутизации трафика.

    Приглашаем под кат инженеров и программистов — всех, кто проектирует железо и разрабатывает софт для сетевых маршрутизаторов. Наши рецепты можно использовать и в секторе SOHO (малый офис / домашний офис), и в сегменте Enterprise (разработка сетевых устройств с высокой производительностью).

    В локальных и глобальных компьютерных сетях стандартом де-факто является передача данных по протоколам Ethernet и TCP/IP. Эти протоколы предусматривают различные топологии с разделением исходных крупных сетей на подсети с применением маршрутизаторов. Простейший вариант построения сети представлен ниже:



    При передаче потока информации от компьютера A к компьютеру B трафик в виде пакетов поступает на интерфейс маршрутизатора eth0, откуда пакет направляется в операционную систему, где последовательно проходит через разные уровни стека протоколов TCP/IP и расшифровывается для определения дальнейшего пути следования пакета. После получения адреса назначения и определения правила перенаправления операционная система снова запаковывает пакет, в зависимости от используемых протоколов, и выводит его через интерфейс eth1. При этом большая часть пакета остается неизменной, меняются лишь некоторые поля его заголовков. Чем быстрее пакет проходит все эти стадии, тем большую пропускную способность сможет обеспечить маршрутизатор. И если во времена сетей с пропускной способностью 100 Мбит/c проблема производительности маршрутизаторов не стояла так остро, то с приходом гигабитных скоростей появилась необходимость в повышении эффективности оборудования.

    Несложно заметить, что такая полная обработка трафика является избыточной для большинства пакетов известного типа. Отсеивая и перенаправляя на раннем этапе пакеты, которые не предназначены самому устройству, можно значительно уменьшить время обработки проходящего трафика. Такая обработка чаще всего проводится еще до операционной системы, что уменьшает временные задержки. Благодаря сведению к минимуму пути прохождения пакетов эта технология получила название fast path. Так как этот способ ускорения зависит от низкоуровневой части сетевого стека и предусматривает обмен информацией с сетевым драйвером, конкретная реализация технологии fast path зависит от используемого оборудования.

    Процесоры Marvell Kirkwood


    Marvell Kirkwood — система на кристалле на базе ARMv5TE-совместимой архитектуры Sheeva. Данные процессоры разработаны специально для использования в сетевых устройствах, таких как маршрутизаторы, точки доступа, STB-устройства, сетевые накопители, медиасерверы и plug-компьютеры.

    Линейка Kirkwood состоит из процессоров с одним или двумя вычислительными ядрами и обширным набором периферии. Рабочие частоты — от 600 МГц до 2 ГГц, вся линейка несет на борту кэш L2 размером 256 КБ. Старшие двухъядерные модели могут похвастаться наличием FPU.

    Основные характеристики процессоров Marvell Kirkwood представлены в таблице:

    Процессор


    Тактовая частота


    Количество ядер


    Интерфейс памяти


    Порты Ethernet


    PCI-Express


    USB 2.0


    SATA 2.0


    88F6321


    800 МГц


    2


    32/40-бит DDR2 до 800 МГц


    2GE


    1


    1


    0


    88F6322


    800 МГц


    2


    32/40-бит DDR2 до 800 МГц


    2GE


    2


    2


    0


    88F6323


    1,0 ГГц


    2


    32/40-бит DDR2 до 800 МГц


    3GE


    2


    3


    1


    88F6282


    1,6—2,0 ГГц


    1


    16-бит DDR2/3 до 1066 МГц


    2GE


    2


    1


    2


    88F6283


    600 МГц


    1


    16-бит DDR2/3 до 1066 МГц


    2GE


    2


    1


    2


    88F6281


    1,0—1,2 ГГц


    1


    16-бит DDR2 до 800 МГц


    2GE


    1


    1


    2


    88F6280


    1,0 ГГц


    1


    16-бит DDR2 до 400 МГц


    1GE


    0


    1


    0


    88F6192


    800 МГц


    1


    16-бит DDR2 до 400 МГц


    2GE


    1


    1


    2


    88F6190


    600 МГц


    1


    16-бит DDR2 до 600 МГц


    1FE+1GE


    1


    1


    1


    88F6180


    600—800 МГц


    1


    16-бит DDR2 до 600 МГц


    1GE


    1


    1


    0



     


    Компонент Network Fast Processing


    Поскольку линейка процессоров Kirkwood ориентирована на применение в том числе и в устройствах перенаправления трафика, Marvell так же столкнулась с необходимостью реализации технологии fast path в своих устройствах. Для решения этой задачи в HAL-часть драйвера поддержки платформы в ядре ОС Linux 2.6.31.8 был добавлен компонент Network Fast Processing, или коротко — NFP.

    Взаимосвязь Marvell NFP с остальными частями операционной системы Linux можно представить следующим образом:



    NFP реализован в виде «прослойки» между драйвером гигабитного интерфейса и сетевым стеком операционной системы. Если кратко, основным принципом ускорения прохождения трафика является отсеивание входящих маршрутизируемых пакетов и вывод их через необходимый интерфейс в обход ОС. Те же пакеты, которые предназначены для локального интерфейса, либо которые невозможно обработать в рамках fast path, направляются в ядро Linux для обработки стандартными средствами.

    Технология fast path, реализованная компанией Marvell, обрабатывает не все возможные форматы пакетов, а только наиболее распространенные протоколы до транспортного уровня модели OSI/ISO. Цепочку поддерживаемых протоколов можно условно представить следующим образом:

    Ethernet (802.3) → [ VLAN (802.1) ] → [ PPPoE ] → IPv4 → [ IPSEC ] → TCP/UDP
    

    В поддержке протоколов более высокого уровня нет необходимости, так как эта информация не используется для маршрутизации трафика. Анализ заголовков транспортных протоколов необходим для работы NAT.

    Благодаря модульной структуре настройку используемых частей можно произвести на этапе компиляции ядра Linux. Можно выделить следующие опциональные части:

    • FDB_SUPPORT — хэш-таблица соответствия MAC-адресов и интерфейсов.
    • PPP — поддержка протокола PPPoE.
    • NAT_SUPPORT — поддержка трансляции IP-адресов.
    • SEC — поддержка протокола шифрования IPSec.
    • TOS — замена поля type of service в IP-заголовке на основании правил iptables.

    FDB (forwarding database) — база данных перенаправления трафика, находящаяся в ядре операционной системы Linux. В отличие от таблицы маршрутизации, FDB оптимизирована для быстрого поиска записей. В реализации fast path компании Marvell используется своя локальная таблица правил ruleDb, запись в которую, как и удаление, осуществляется из сетевого стека ОС (для этого в код стека внесены соответствующие изменения).

    Для быстрого поиска ruleDB представляет собой хэш-таблицу с парами ключ-значение, где значением является правило перенаправления пакета с определенным адресом назначения, а ключом для быстрой индексации этого правила — индекс, сгенерированный из адресов источника и назначения с помощью специальной хэш-функции. Оптимально составленная хэш-функция гарантирует максимальные шансы того, что одному индексу будет соответствовать одно правило.

    Поскольку изначально FDB (а следовательно, и ruleDb) пуста, каждый первый пакет (пакет без существующей записи в FDB) направляется в ядро ОС, где после обработки и создается правило. После истечения определенного таймаута эта запись будет удалена из FDB и из ruleDB в NFP.

    Рассмотрим процесс обработки трафика более подробно:

    1. На вход NFP передаются raw-данные полученного пакета.
    2. Если пакет предназначен multicast MAC-адресу, он направляется в TCP/IP-стек ОС.
    3. Если используется FDB и в таблице нет записи для этого MAC-адреса, пакет отправляется в стек ОС.
    4. Из FDB извлекается запись для данного MAC-адреса. Если адрес не помечен как локальный, система опознает его как соединенный в режиме bridge и отправляет пакет через интерфейс, указанный в записи таблицы FDB.
    5. Если обнаружено наличие заголовка VLAN или PPPoE, он отбрасывается, и вычисляется ссылка на начало IP-заголовка.
    6. Помеченные как фрагменты пакеты передаются в сетевой стек ОС.
    7. Если в пакете содержатся данные протокола ICMP, пакет направляется в стек.
    8. Пакеты с истекшим временем жизни отправляются в стек ОС. Конечно, такие пакеты должны быть отброшены, но при этом средствами операционной системы должен быть сгенерирован ICMP-ответ TTL expired.
    9. Происходит проверка на наличие заголовка протокола IPSec и соответствующая обработка таких пакетов с проверкой сертификата.
    10. Далее происходит поиск правила Destination NAT с целью определения IP-адреса назначения для этого пакета.
    11. Если для имеющегося адреса назначения не существует маршрута — пакет направляется в сетевой стек. Такие пакеты также должны быть отброшены, однако необходимо сгенерировать соответствующий ICMP-ответ.
    12. Далее происходит поиск правила Source NAT и обновление полей заголовков IP и TCP/UDP с учетом правил DNAT и SNAT.
    13. На основании таблицы маршрутизации происходит вычисление интерфейса, через который необходимо вывести пакет.
    14. Если для выходного интерфейса используется туннелирование PPP, IP-пакет оборачивается заголовком PPPoE, предварительно уменьшив TTL и обновив заголовок Ethernet. Поскольку в данном случае контрольную сумму IP-пакета невозможно посчитать аппаратным способом, необходимо пересчитать контрольную сумму. Но так как известна старая контрольная сумма и изменение данных пакета, сумма не вычисляется полностью, а лишь корректируется на необходимое значение.
    15. Если размер пакета превышает максимальный — пакет направляется в стек ОС.
    16. В остальных случаях происходит обновление заголовка Ethernet, контрольной суммы, и поля type of service (при необходимости и наличии записи в iptables).
    17. Полученный Ethernet-пакет выводится через соответствующий сетевой интерфейс.

    Данную последовательность проверок можно представить графически в виде диаграммы:


    Диаграмма «Обработка пакета в NFP»

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

    Что касается недостатков реализации технологии fast path в компании Marvell, нельзя не заметить случаи направления трафика в ядро ОС при любой необходимости генерации ICMP-пакетов. Это приведет к повышенной нагрузке на маршрутизатор в случае сетевых атак или любого другого повышенного количества ICMP-трафика.

    В случае большого объема multicast-трафика маршрутизатор также будет испытывать повышенную нагрузку, поскольку этот трафик не обрабатывается NFP и проходит через сетевой стек ОС.

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

    Что касается недостатков технологии fast path в целом, можно заметить тот факт, что она в любом случае делит процессорное время с операционной системой, а значит использует не все возможные ресурсы. Данную проблему легко решают многопроцессорные решения Marvell, такие как четырехъядерные процессоры Armada XP.

    Измерение производительности маршрутизатора


    Насколько сильное влияние на производительность маршрутизатора оказывает применение Network Fast Processing в реальных системах? Для ответа на этот вопрос оценим скорость пакетов, проходящих через маршрутизатор с включенным и выключенным NFP.

    В качестве тестового устройства возьмем маршрутизатор на базе систему на кристалле Marvell Kirkwood 88F6282 с тактовой частотой 1 ГГц. Этот процессор имеет на борту два сетевых интерфейса 1000Base-TX, что делает его хорошим выбором для данного типа устройств.


    На схеме: архитектура СнК Marvell Kirkwood 88F6282

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

    PackETH — утилита с графическим интерфейсом для генерации Ethernet-кадров, существуют ее версии под ОС Linux, Windows и Mac. Это один из самых простых в использовании инструментов для генерации трафика, он обладает следующими возможностями:

    • Генерация кадров Ethernet II, Ethernet 802.3, 802.1q, QinQ или определяемых пользователем.
    • Поддержка протоколов ARP, IPv4, IPv6, UDP, TCP, ICMP, ICMPv6, IGMP, RTP (с возможностью задания полезной нагрузки) или определяемых пользователем.
    • Генерация Jumbo-фреймов (в случае поддержки драйвером).
    • Посылка очереди пакетов с настраиваемой задержкой и количеством пакетов.
    • Возможность сохранения настроек.

    Графический интерфейс утилиты выглядит следующими образом:


    Интерфейс утилиты PackETH

    iperf — другое решение для генерации трафика, оно гораздо более распространенное, но практически не предлагает возможностей по настройке формата пакетов. Эта консольная утилита умеет измерять пропускную способность сети, генерируя и принимая пакеты TCP и UDP.

    Для ее использования достаточно запустить одну копию приложения в режиме сервера командой:

    # iperf -s
    

    И другую копию на второй машине в режиме клиента с указанием адреса или имени сервера:

    # iperf -c server_host
    

    В течение 10 секунд программа измерит пропускную способность сети и выдаст результат.

    Также возможность непосредственной генерации UDP-трафика предоставляет модуль ядра pktgen. Настроить параметры генерируемых пакетов можно через директорию /proc/net/pktgen файловой системы procfs. Простейшая конфигурация задается следующим образом:

    # echo "add_device eth0" > /proc/net/pktgen/kpktgend_0
    # echo "count 1000" > /proc/net/pktgen/eth0
    # echo "dst 192.168.1.1" > /proc/net/pktgen/eth0
    # echo "pkt_size 1000" > /proc/net/pktgen/eth0
    # echo "delay 50" > /proc/net/pktgen/eth0
    

    Запускаем генератор:

    # echo "start" > /proc/net/pktgen/pgctrl
    

    После завершения работы генератора в его статусе /proc/net/pktgen/eth0 отобразится скорость отправки.

    Основное преимущество pktgen состоит в том, что он генерирует пакет для передачи только один раз, а затем посылает копии этого пакета, что позволяет достичь более высоких скоростей.

    Есть и другие решения для генерации трафика и измерения пропускной способности сети, такие как brute, netperf, mpstat или sprayd.

    Поскольку перед нами нет задачи проверки всех возможных случаев, будет достаточно возможностей iperf. Будем передавать пакеты TCP и UDP размером 1400 байт в двух режимах — с отключенным и включенным Network Fast Processing. Непосредственное управление NFP можно осуществлять через procfs с помощью менеджера /proc/net/mv_eth_tool.Например, для того чтобы отключить NFP достаточно послать менеджеру команду «c 0»:

    # echo "c 0" > /proc/net/mv_eth_tool
    

    Где «c» — код команды, «0» — устанавливаемый статус NFP.

    Измерим производительность сети в этих режимах и занесем результаты:

    Тип пакетов


    TCP


    UDP


    Размер пакета, байт


    1400


    1400


    Пропускная способность без NFP, Мбит/с


    281


    338


    Пропускная способность с NFP, Мбит/с


    551


    552



    Поскольку реальная пропускная способность сильно зависит от конфигурации устройства и запущенных приложений, ориентироваться на полученные абсолютные значения не стоит. Но в первую очередь нас интересует рост производительности при включении NFP. Как видим, в случае TCP-трафика пропускная способность возросла почти в два раза (на 96%), что довольно ощутимо. Для UDP-пакетов эффект не такой сильный — зафиксирован рост на 63%, но и это неплохой результат.

    Примеры наших разработок



    1. Один из примеров наших разработок, в которых была использована технология fast path — тонкий-клиент AK1100, о котором мы уже рассказывали на Хабре. Аппаратная платформа этого устройства построена на базе Marvell Kirkwood 88F6282 (ядро Sheeva; 1,6 ГГц). Этот процессор имеет два гигабитных Ethernet (подключены к внешнему PHY 88E1121R от Marvell) и два порта PCIe: первый порт используется для подключения GPU, а второй — выведен на внутренний разъём mini-PCI, к которому можно подключать дополнительные внешние устройства или модули WI-FI. Более подробно о проекте с технической точки зрения рассказано тут: разработка тонкого-клиента.
    2. Еще один пример — мини-сервер IP-Plug — первый в России коммерческий plug-компьютер и наш первый проект на процессоре Marvell. Устройство было спроектировано на базе Marvell Kirkwood 88F6283 и Linux Debian 6.0. Мы еще расскажем на Хабре о том, как поставили на этот плаг NetBSD, а пока внимательные читатели могут познакомиться с подробным описанием девайса тут: разработка мини-сервера.


    Выводы


    Казалось бы, на современном уровне развития техники такая проблема как недостаток производительности должна стать неактуальной. Однако в некоторых проектах разработчики дизайн-центра электроники Promwad всё же сталкиваются с необходимостью контроля энергопотребления или жесткими стоимостными рамками. В таких случаях NFP помогает нам значительно повысить эффективность устройства исключительно программным способом.

    Конечно, Network Fast Processing не является универсальным решением, а в случае использования нестандартных протоколов может даже помешать корректной маршрутизации трафика. Но в большинстве случаев инженеры-программисты могут оптимизировать NFP к заданным условиям и получить в разработанных устройствах все преимущества технологии fast path.
    Promwad
    Контрактная разработка и производство электроники

    Comments 2

    • UFO just landed and posted this here
        +1
        Собственно там под табличкой специально указано, что не надо смотреть на абсолютные цифры. Эти данные получены не на отдельном тестовом стенде, а на живом готовом устройстве, на котором кроме этого крутилось еще много всего (например, Asterisk).
        Данные приведены больше чтобы показать, что технология на самом деле работает. А т.к. получить настоящий гигабит роутинга через TCP/IP стек Linux на ARM/MIPS задача не тривиальная, большинство производителей сетевого оборудования сейчас так или иначе используют похожие технологии. В высокочастотном трейдинге, например, вообще не стесняются кромсать TCP/IP стек направо и налево, и ничего.

      Only users with full accounts can post comments. Log in, please.