Intel 82599: ограничиваем выходную скорость

    Всем привет!

    В этой статье я хочу рассказать вам про одну полезную фичу, которая есть в сетевой карте Intel 82599.
    Речь пойдёт об аппаратном ограничении скорости выходного потока пакетов.

    К сожалению, она не доступна в линуксе «из коробки» и требуются некоторые усилия, чтобы её задействовать.
    Кому интересно — добро пожаловать под кат.





    Началось всё с того, что на днях мы тестировали оборудование, которое занимается фильтрацией трафика.



    Девайс MX — это DPI-устройство. Оно разбирает пакет, поступающий из 10G и отправляет его на гигабитный порт, если он попадает под заданный критерий (адреса, порты и прочее). На стороне PC — карта Intel 82599 с драйвером ixgbe. Трафик генерировали при помощи tcpreplay, а собирали при помощи tcpdump. Дамп с тестовым трафиком у нас был (дано по условиям задачи).

    Поскольку в общем случае отфильтровать 10G и отослать результат в 1G не представляется возможным (скорости-то разные, а буферы не резиновые), нам пришлось ограничивать скорость генерации пакетов. Тут важно сказать, что мы проводили не нагрузочное тестирование, а функциональное, поэтому нагрузка на 10G была не очень важна и влияла только на длительность теста.

    Казалось бы, задача решается просто: открываем man tcpreplay и видим там ключик -M.
    Запускаем:

    $ sudo tcpreplay -M10 -i eth3 dump.cap
    


    В результате в статистике MX'а появляется следующее:
    | Name          | Packets        | Bytes          | Overflow pkt   |
    | EX1     to EG1|          626395|       401276853|              53|
    | EX1     to EG2|               0|               0|               0|
    | EX1         RX|        19426782|      4030345892|               0|
    


    Столбец overflow pkt означает, что часть пакетов не «влезла» в 1G, т.к. выходной буфер переполнился. А это значит, что до PC не дошло 53 пакета. А они нам очень нужны, ведь мы проверяем правильность функционирования фильтров.

    Получается, что сетевая карта 82599 создаёт burst'ы независимо от того, какая скорость выставлена в tcpreplay.

    Встал вопрос о том, как можно контролировать нагрузку в 10G на уровне, максимально приближенном к линку. И тут нам в голову пришла мысль, что карта это уже умеет. Так и есть! В datasheet'e нашли подтверждение в разделе 1.4.2 Transmit Rate Limiting. Осталось только научиться этой функцией управлять.

    Рычагов для этого (нужных файликов в sysfs) в нашем ядре мы не нашли (мы игрались c 3.2, debian). Порылись в сорцах свежего ядра (3.14) и там тоже не нашли.

    Оказалось, что на github'е уже есть проект, который называется tx-rate-limits.

    Дальше всё тривиально :) Собрали ядро, поставили на систему:
    $ git checkout https://github.com/jrfastab/tx-rate-limits.git
    $ cd tx-rate-limits
    $ fakeroot make-kpkg --initrd -j 8 kernel-image
    $ sudo dpkg -i ../linux-image-3.6.0-rc2+_3.6.0-rc2+-10.00.Custom_amd64.deb
    


    Перезагрузились, и… в sysfs теперь есть файлики для управления нагрузкой передачи!
    $ ls /sys/class/net/eth5/queues/tx-0/
    byte_queue_limits  tx_rate_limit  tx_timeout  xps_cpus
    


    Дальше записываем в tx_rate_limit требуемое значение в мегабитах:

    # RATE=100
    # for n in `seq 0 7`; do echo $RATE > /sys/class/net/eth4/queues/tx-$n/tx_rate_limit ; done
    


    В итоге в статистике MX'а видим, что overflow не происходит, т.к. скорость контролируется картой и burst'ов больше нет, весь отфильтрованный трафик попадает в 1G без потерь:

    | Name          | Packets        | Bytes          | Overflow pkt   |
    | EX1     to EG1|        22922532|     14682812077|               0|
    | EX1     to EG2|               0|               0|               0|
    | EX1         RX|       713312575|    147948837844|               0|
    


    Возможно, для решения данной задачи есть более простой способ.

    Буду очень благодарен, если кто-нибудь поделится.

    UPD:
    Забыл написать, как работает Transmit Rate Limiting.

    Он модифицирует IPG (Inner Packet Gap). То есть на канальном уровне контролирует задержки между пакетами.
    Таким образом, мы имеем аппаратный контроль за интервалом времени между пакетами и равномерный поток пакетов.
    И главное — есть аппаратная гарантия отсутствия burst'ов :)
    НТЦ Метротек
    Разработка и производство Ethernet устройств etc.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 21

      0
      почему бы просто не шейпнуть траффик?
        0
        это мысль ;) но 10-гигабитного шейпера под рукой не оказалось. btw, с помощью tx-rate-limit можно его сделать самому
          0
          /sbin/tc?
            0
            Спасибо большое, не знал. Ушёл читать :)
              0
              Есть такая штука — LARTC — крайне рекомендуется к прочтению для любого применения линуксов в сетях.
              +1
              Насколько я понял из документации, tc привязывается к системному HZ, на нашей машинке это 250. То есть квант времени для tc —
              это 4 миллисекунды. То есть, если мы хотим посылать больше 250 пакетов в секунду, пакеты будут посылаться пачками.

              Например, если мы хотим ограничить выходной поток 100 Мбит/c и размер пакета у нас 1000 байт (= 8000 бит), то 250 раз в секунду будет послана пачка из 50 пакетов (100e6/8e3/HZ).

              Получается, что от burst'ов мы средствами tc не избавимся.

              Протестировали на описанной схеме: фиксируем overflow pkt.

              btw, не написал в статье, как работает Transmit Rate Limiting, сейчас дополню

                0
                это смотря как его построить. давайте-ка ваш конфиг.
                  0
                  вы хотите сказать, что tc может гарантировать равномерное распределение пакетов во времени?
                  я не нашёл этого в документации…
                    0
                    если не ошибаюсь, параметр burst за это отвечает.
                      0
                      Да документация у tc просто «устрашающая»…
                      Почитайте тут, может поможет (кто-то у нас эту статью в вики положил когда с tc разбирался)…
                      Networking: Using Linux Traffic Control for Fun and Profit Loss Prevention
                      0
                      команду пришлю в понедельник
                        0
                        мы вот такой строкой тестировали

                        tc qdisc add dev eth4 root tbf rate 500mbit burst 2000 latency 1us

                        мне кажется, что в ней чего-то не хватает, если честно.
                        буду разбираться дальше.
                          0
                          cходу скажу только, что буфер (burst) маловат. пруф из документашки:

                          For 10mbit/s on Intel, you need at least 10kbyte buffer if you want to reach your configured rate
                0
                Почему бы просто не перевести карту на скорость 1G?
                  0
                  В этом случае линк будет 1G?
                    0
                    Конечно)
                    Судя по даташиту сетевой карты, она поддерживает 100M/1G/10G.
                    Какой выставим — такая скорость и будет.
                      0
                      MX не поддерживает меньше 10G, к сожалению
                        0
                        А если поставить коммутатор с 1G и 10G портами?
                          0
                          отличное решение… нам почему-то в голову не пришло, хотя 10-гигабитных коммутаторов — хоть отбавляй.
                          Но уж очень хотелось поковыряться с intel'овской карточкой :)

                          0
                          Как тогда работает второй линк MX на 1G?
                            0
                            У MX в данной прошивке два порта 10G работают на вход, и два порта 1G на выход. Закладывать гибкую коммутацию в него не стали, так как сожрёт ресурсы ПЛИС.

                            Вообще, поскольку прошивка в наших руках, могли сварганить любую комбинацию, в том числе и 1Г-1Г, но в этом случае
                            мы бы тестировали уже другую прошивку, а не ту, которая уходит в production.

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

                  Самое читаемое