The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск сетевого стека F-Stack 1.24, выполняемого в пространстве пользователя

19.10.2024 21:43

Опубликован сетевой стек F-Stack 1.24, представляющий собой редакцию сетевого стека FreeBSD, работающую в пространстве пользователя и использующую фреймворк DPDK для достижения максимальной производительности. Проект создан крупнейшей в Китае телекоммуникационной компанией Tencent и используется в её продуктах и сервисах. Код написан на языке Си и распространяется под лицензией BSD. Поддерживается работа в Linux и FreeBSD.

F-Stack позволяет задействовать в приложениях собственный локальный сетевой стек, не зависящий от сетевого стека операционной системы, функционирующий в пространстве пользователя и напрямую работающий с сетевым оборудованием. F-Stack позиционируется как решение, позволяющее повысить производительность обработчиков сетевых запросов в условиях, когда штатный TCP/IP стек ядра Linux становится узким местом и ограничивает масштабирование - в некоторых ситуациях проект даёт возможность в разы увеличить число обрабатываемых мелких сетевых запросов. Теоретически F-Stack позволяет достигнуть потолка сетевой производительности, возможного для используемой сетевой карты.

Повышение производительности достигается за счёт исключения таких операций, как копирования сетевых пакетов, планирование потоков, обработка прерываний и применение системных вызовов. Для взаимодействия с сетевой картой, минуя интерфейсы ядра операционной системы, применяется фреймворк DPDK (Data Plane Development Kit), развивающий набор библиотек для низкоуровневой работы с сетевыми адаптерами. DPDK даёт возможность снизить накладные расходы и уложиться в минимальное число циклов CPU при приёме или отправке сетевых пакетов.

Функциональность стека TCP/IP соответствует сетевому стеку FreeBSD 13 и выделена из данной операционной системы в независимую библиотеку. Для разработки приложений можно использовать стандартный API POSIX (socket, epoll, kqueue) или собственный программный интерфейс на основе микропотоков, упрощающий создание сетевых приложений и позволяющий обойтись без сложной логики асинхронной обработки запросов.

Проектом поддерживаются переведённые на использование F-Stack редакции многопротокольного сервера Nginx 1.25.2 и СУБД Redis 6.2.6, демонстрирующие производительность выше обычных сборок, работающих поверх системного сетевого стека.

Наиболее заметные изменения в новом выпуске:

  • В файле конфигурации config.ini предоставлена возможность выбора между использованием KNI (Kernel NIC Interface) и virtio_user в качестве транспорта для передачи пакетов между ядром и приложением обработки пакетов на базе DPDK. Добавлена возможность использования ratelimit для KNI.
  • Добавлена поддержка включения настройки сетевого стека "net.add_addr_allfibs=1" для добавления адресов во все таблицы маршрутизации.
  • Добавлен API ff_get_traffic для получения трафика, например, для реализации QoS (Quality of Service).
  • Добавлены функции pthread_create и pthread_join, напоминающие аналогичные функции из POSIX.
  • Добавлен API ff_dpdk_raw_packet_send для отправки приложением raw-пакетов напрямую через DPDK, а не через сокет.
  • Реализована поддержка автоматической настройки VLAN, маршрутизации и policy routing.
  • Осуществлён переход на версию DPDK 22.11.6 LTS.
  • В реализации Nginx поверх F-Stack добавлена поддержка модуля stream.


  1. Главная ссылка к новости (https://github.com/F-Stack/f-s...)
  2. OpenNews: Выпуск DPDK 18.02, фреймворка для высокопроизводительных сетевых приложений
  3. OpenNews: Fastsocket - новая высокомасштабируемая реализация сетевой подсистемы ядра Linux
  4. OpenNews: Выпуск системы глубокого инспектирования пакетов nDPI 4.10
  5. OpenNews: Intel представил сокращённый вариант сетевого стека для Linux
  6. OpenNews: Проект LibOS развивает вариант ядра Linux с сетевым стеком в форме библиотеки
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62076-f-stack
Ключевые слова: f-stack, dpdk
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (50) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, Аноним (4), 22:56, 19/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Т.е. они сп-ли сетевой стек freebsd, скомпилив его под dpdk'шную ebpf (или что там еще) фигню? И оно в юзерленде через две прослойки и три прокладки оказалось быстрее чем оригинальный стек линукса?

    Ну ооок...

     
     
  • 2.6, 1 (??), 23:08, 19/10/2024 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ну я так понимаю что переключений контекста не происходит, так как все в userland
     
     
  • 3.30, нах. (?), 10:23, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Угу, доступ к прямому управлению сетевой картой - в userland. Ага, дайте две.

    (FreeBSD 20 лет назад - accf_http, accf_data. Чтобы отдавать в юзерленд готовые структуры данных конкретного приложения, а не по одному пакету с неизвестным содержимым (который может вообще придется выбросить и захлопнуть сокет - и это уж точно можно сделать прямо в ядре). Л@п4@тые сегодня: отдадим raw ethernet frames и управление регистрами сетевухи. Так - тооочно быстрее!

     
     
  • 4.35, Аноним (-), 11:50, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > (FreeBSD 20 лет назад - accf_http, accf_data. Чтобы отдавать в юзерленд
    > готовые структуры данных конкретного приложения

    С тех пор http немного поубавил популярности.

    >  raw ethernet frames и управление регистрами сетевухи. Так - тооочно быстрее!

    Китайцам то? С GFW? Зачем им твой хттп, вот проксю или впн зобанить - это да, тема. Приложеньки у них специфичные.

     
     
  • 5.44, нах. (?), 20:44, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > С тех пор http немного поубавил популярности.

    с тех пор и ktls завезли. А у больших у многих все по прежнему, кстати - шифрование выполняется специальными ящиками на границе периметра (где, кстати, уже можно плевать на переключения контекстов, все равно все пожрет - само шифрование). Внутри сплошь http - по многим причинам. У самых альтернативно-пряморуких там даже http2 (не спрашивай зачем).

    > Китайцам то? С GFW?

    зачем бы gfw nginx и redis?

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

    А эти либо хостят, либо массовый клауд либо еще что подобное. Вполне себе белое и пушистое.

     
     
  • 6.58, Аноним (-), 22:30, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот кстати процы сейчас довольно резвые - и шифрование в общем то тоже И да,... большой текст свёрнут, показать
     
  • 2.52, Аноним (52), 13:08, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Причем, если вы думаете, что это только в Linux все так печально, то ошибаетесь!

    Windows тоже годами переходит на сетевой стек FreeBSD. Microsoft выкинул все старые наработки по сетям и начал этот переход активно с Server 2016/Windows 10. Результаты там были еще хуже чем с Linux...

     
  • 2.55, randomize (?), 16:30, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Из *BSD невозможно ничего сп-ть - читай лицензию.
     

  • 1.7, Аноним (7), 23:08, 19/10/2024 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +4 +/
     

     ....ответы скрыты (2)

  • 1.8, Ivan_83 (ok), 23:26, 19/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Интересно они осилили RACK или оно только с дефолтной TCP реализацией работает?
     
     
  • 2.53, Аноним (52), 14:12, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде смогли еще в версии 1.22, но я не могут точно сказать насколько этот функционал FreeBSD Only.

    Вообще, на уровне ядра RACK работает только во FreeBSD и Windows, остальные ОС CUBIC-и мнут себе.

     

  • 1.9, Аноним (-), 00:07, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Файрвол в нём можно настроить?
     
  • 1.15, Аноним (15), 04:44, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На полянке HFT станет ещё теснее?
     
  • 1.19, Ember (?), 08:12, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Это же какой bullshit из себя представляет Linux, что проще портировать сетевой стек(!) из другой ОС, чем исправить нативный.

    Я теперь не вижу ничего удивительного в том, что никто не в состоянии починить tty. Видимо, там такая помойка, что всё попросту развалится, если пошевелить.

    Серверная система без без консоли и сетевого стека... Позорище, что тут ещё сказать.

     
     
  • 2.20, Аноним (20), 08:30, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +5 +/
    F-Stack быстрее и при работе во FreeBSD. Переключение контекста очень затратная операция. С тем же успехом можно было бы вынести в userspace библиотеку сетевой стек Linux, но стек Linux раздут и притянут к куче разных подсистем, а TCP/IP стек FreeBSD и ядро FreeBSD заметно проще, предсказуемее и меняются не так интенсивно.

    Сравните https://github.com/freebsd/freebsd-src/tree/main/sys/net и https://github.com/torvalds/linux/tree/master/net

     
     
  • 3.28, Аноним (28), 09:32, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по факту этот ваш комментарий как монолог Тони "Пуля в зубах" из снетча. "Только ты попутал, и никакой демонстрации годности бсд систем здесь нет."
     
     
  • 4.38, Ember (?), 11:57, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Само существование F-Stack является прямой демонстрацией годности *BSD. Ну или негодности Linux, как тебе больше нравится.
     
  • 3.36, Аноним (-), 11:52, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > сетевой стек Linux, но стек Linux раздут и притянут к куче
    > разных подсистем,

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

    А сравнить - достаточно фаер в линухе и фаеры в бсд. Сразу видно где просто позор какой-то.

     
     
  • 4.39, Ember (?), 12:01, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Бла, бла, бла и бла. Сколько маркетингового порожняка. На деле же линуксовый сетевой стек вместо с его убогим nftables без шансов сливают фряшным аналогам.
     
     
  • 5.42, Аноним (-), 19:48, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Бла, бла, бла и бла. Сколько маркетингового порожняка. На деле же линуксовый
    > сетевой стек вместо с его убогим nftables без шансов сливают фряшным аналогам.

    И чему именно nftables сливает? И кому из? Он так то довольно шустрый, фичастый, с неких пор умеет офлоад flow в fast path, скипая большую часть процесинга, умеет всякие забавные вещицы... вон там борцы за ютуб из него аж контр-DPI вылепили.

     
     
  • 6.54, Мне хватает (?), 14:34, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Такой обширный список железа умеет hw offload, красота
     
     
  • 7.60, Аноним (-), 22:35, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Такой обширный список железа умеет hw offload, красота

    Он и SW офлоад умеет - примерно так же по смыслу: после того как flow посчитан подлежащим пропуску, можно заскипать большую часть процессинга и отпуливать пакеты в софтварный вариант fast path. Это имеет свои особенности - но в целом работает.

     
     
  • 8.67, Ну блин (?), 23:28, 22/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    план действий https man freebsd org cgi man cgi query ipfw найти check-state ... текст свёрнут, показать
     
  • 5.46, Anonimous (?), 07:35, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Где? По новостям и по вакансиям линукс везде побеждает. У вас какой-то свой мир где у линукса нет шансов?
     
  • 5.48, Аноним (48), 09:19, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    afair, во фре нет даже аналога
    -m string
     
     
  • 6.66, Ну блин (?), 23:28, 22/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    ну да, ну да, данные внутри IP-пакета как раз должны фаером L3 проверяться, а не специальным протокольным фильтром L7, ага.
     
  • 2.45, нах. (?), 20:46, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я теперь не вижу ничего удивительного в том, что никто не в
    > состоянии починить tty.

    а раньше типа не догадывался?
    > Видимо, там такая помойка, что всё попросту развалится,
    > если пошевелить.

    в том который kms'ный псевдотекстовый - именно так все и есть. (а другого в новых модных линуксах и не положоно иметь)

    > Серверная система без без консоли и сетевого стека... Позорище, что тут ещё

    ну не то чтобы уж совсем, но да, с замысловатыми...

     
     
  • 3.62, Аноним (-), 22:42, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > в том который kms'ный псевдотекстовый - именно так все и есть. (а
    > другого в новых модных линуксах и не положоно иметь)

    Вообще то там основной факапище - подсистема VT. И таки - ее - вот - пришлось таки малость отрефакторить. Невзирая на боль и ужас. PREEMPT_RT вон тем хотелось. Да, умение в гарантии RTOS это достаточно сильная замануха чтобы поднапрячься. И это хотят довольно толстые коты, типа автомотивщиков всяких, индустриалов и прочие (около)эмбедовочные.

     
  • 2.47, microcoder (ok), 08:10, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это же какой bullshit из себя представляет Linux, что проще портировать сетевой стек(!

    С чего ты взял? Быстрее не значит секьюрней. Как только начнут докручивать этот F-Stack для реальных задач он станет в несколько раз тормознее. Это обычная практика.

     

  • 1.21, YetAnotherOnanym (ok), 08:38, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А откуда ядро знает, кому отдавать фрейм, если оно его не обрабатывает?
     
     
  • 2.24, Аноним (20), 09:07, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    А оно и не знает, отдаёт отдельный TCP/IP стек в userspace, обращающийся напрямую с сетевой картой.


     
  • 2.34, нах. (?), 11:47, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    никак, сетевуха монопольно занята ЭТИМ вот. Если тебе нужно к примеру управление - подключай рядом вторую.

    Т.е. ВСЕ вообще фреймы отдаются вот туда, без разбора и обработки. (там вроде бы как-то можно потом вернуть необработанное обратно ведру, но это неточно, да и эффективность понятно какая)

     
     
  • 3.37, Аноним (-), 11:54, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > никак, сетевуха монопольно занята ЭТИМ вот. Если тебе нужно к примеру управление
    > - подключай рядом вторую.

    А in-band послать данные управления своей приложухе религия в принципе не прзволяет? Или ты даже и близко не надеешься уметь это секурно? :)

    > Т.е. ВСЕ вообще фреймы отдаются вот туда, без разбора и обработки. (там
    > вроде бы как-то можно потом вернуть необработанное обратно ведру, но это
    > неточно, да и эффективность понятно какая)

    А зачем тебе какая-то убер эффективность в управлении, которого by design мизер?

     
  • 2.56, Аноним (56), 17:22, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Почитай как работает DPDK, VPP, DMA
     
     
  • 3.57, YetAnotherOnanym (ok), 18:30, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Этот совет я и сам кому угодно дать могу.
     

  • 1.22, username (??), 08:54, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Забавная получается ситуация: во фряху тащат фреймворки для облегчения портирования доайверов из линукса, а в линукс тащат целые подсистемы из фряхи, ибо фряха отличная ОС без драйверов, а линукс отстойный, но с дровами.
     
     
  • 2.27, Аноним (27), 09:17, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не, просто лицензия пермессивная.
     

  • 1.25, Аноним (27), 09:15, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А что не сразу PF_RING?
     
  • 1.26, Аноним (27), 09:16, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >Проект создан крупнейшей в Китае телекоммуникационной компанией Tencent и используется в её продуктах и сервисах

    В "файрволе" что ли?

     
  • 1.33, Аноним (-), 11:47, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > за счёт исключения таких операций, как копирования сетевых пакетов,
    > планирование потоков, обработка прерываний и применение системных вызовов

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

     
     
  • 2.40, Аноним (40), 12:20, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На сайте F-Stack  написано, что актуально: Therefore, kernel bypass can avoid performance bottlenecks caused by kernel packet copy, thread scheduling, system calls and interrupt.
     
     
  • 3.43, Аноним (-), 19:49, 20/10/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > На сайте F-Stack  написано, что актуально: Therefore, kernel bypass can avoid
    > performance bottlenecks caused by kernel packet copy, thread scheduling, system calls
    > and interrupt.

    Как говорится, сам себя не похвалишь - никто не похвалит. Уже есть варианты без копирования пакетов.

     

  • 1.41, Аноним (41), 16:57, 20/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Чтобы это работало быстро, по идее надо вместо preemptive multitasking делать cooperative multitasking.

    Тогда никаких тебе неожиданных прерываний посередине дорогой операции. "Отдам управление, когда закончу."

    Вообще не знаю на счёт стека Фряхи, но я смотрел своими глазами на стек Опёнка и Линукса, и, ну, типа, Опёнок сильно пахнет девяностыми, а А Линукс в целом, вполне ничего, хотя и малость заумно.

    Хотя мне тоже непонятно, зачем сетевая подсистема в ядре. Ядро, по хорошему, должно только давать гипотетическому networkd облать памяти, mmap'нутую на сетевую карту, и всё. Можно даже просто mmap на /dev/networkcard0.

     
     
  • 2.50, Соль земли (?), 10:19, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Пили. Прогонишь потом тесты, если будет быстрее/удобнее.
     

  • 1.49, Соль земли (?), 10:03, 21/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм, кто бы мог подумать, что отказ от прерываний и системных вызовов увеличить производительность.
     
     
  • 2.63, Аноним (-), 22:47, 21/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Хм, кто бы мог подумать, что отказ от прерываний и системных вызовов
    > увеличить производительность.

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

    К сожалению подстава в том что система становится по сути однозадачной, а работа в стиле MSDOS в XXI веке впечатляет не всех. Хотя в случае многоядерных процов возможны варианты. Ну вот выделить ядро под окучивание сети. И хрен с ним что оно в полку занято, других навалом же есть. Рассматривайте его как очень жирный и программируемый DMA-автомат :)

     

  • 1.64, Аноним (64), 21:47, 22/10/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Драйвер NTFS, работающий в пространстве пользователя, почему-то не радует производительностью. Халтура?
     
     
  • 2.65, Аноним (20), 22:01, 22/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    FUSE-драйверы дёргают ядро при каждом обращении к накопителю, переключений контекста там больше.
    Производительность была бы при прямом обращении минуя ядро, но аналога DPDK для блочных устройств ещё не завезли.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру