The OpenNET Project / Index page

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

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

18.11.2019 11:37

После полутора лет разработки состоялся выпуск проекта F-Stack 1.13, развивающего работающий в пространстве пользователя высокопроизводительный сетевой стек, основанный на фреймворке DPDK и TCP/IP стеке FreeBSD (F-Stack не привязан к FreeBSD и в качестве первичной платформы для применения рассматривает Linux). Проект используется в различных продуктах и сервисах Tencent, крупнейшей в Китае телекоммуникационной компании. Код распространяется под лицензией BSD. Поддерживается работа в Linux и FreeBSD.

F-Stack даёт возможность организовать сетевое взаимодействие в приложениях, применяя вместо сетевого стека операционной системы собственный сетевой стек, функционирующий в пространстве пользователя и напрямую работающий с сетевым оборудованием. Предоставляются специализированные редакции Nginx и Redis, переведённые на использование F-Stack.

Для разработки приложений поддерживается как штатный Posix API (Socket, Epoll, Kqueue), упрощающий перевод на F-Stack существующих приложений, так и собственный программный интерфейс на основе сопрограмм (микропотоков), упрощающий создание сетевых приложений и позволяющий обойтись без сложной логики асинхронной обработки запросов. F-Stack также предоставляет средства для упрощения применения в приложениях с многопроцессной архитектурой.

Для взаимодействия с сетевой картой, минуя интерфейсы ядра операционной системы, применяется фреймворк DPDK (Data Plane Development Kit), предоставляющий набор библиотек для низкоуровневой работы с сетевыми адаптерами, взаимодействия в многоядерных системах, задействования кольцевых буферов и больших страниц памяти ("huge page"). Использование DPDK даёт возможность принимать и отправлять сетевые пакеты с выполнением минимального числа циклов CPU (около 80 циклов на пакет) и разрабатывать высокопроизводительные компоненты сетевого стека. Непосредственно функциональность TCP/IP стека заимствована из FreeBSD 11.1 и выделена в независимую от операционной системы библиотеку.

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

Увеличение производительности достигается за счёт исключения таких операций, как копирования сетевых пакетов, планирование потоков, обработка прерываний и применение системных вызовов. F-Stack позволяет достигнуть потолка сетевой производительности, возможного для используемой сетевой карты. Например, решения на базе F-Stack продемонстрировали возможность обработки 10 млн параллельных соединений, 5 млн запросов в секунду и 1 млн соединений в секунду.

В новом выпуске:

  • Добавлена поддержка VLAN;
  • Обеспечена возможность работы в изолированных контейнерах на базе Docker;
  • Реализованы интерфейсы ff_dup, ff_dup2, ff_ioctl_freebsd, ff_getsockopt_freebsd и ff_setsockopt_freebsd;
  • Добавлен параметр "idle_sleep" для сокращения нагрузки на CPU в ситуации отсутствия входящих пакетов;
  • Добавлена поддержка сборки для архитектуры ARM64;
  • В переведённой на F-Stack редакции Nginx заменены обработчики getpeername, getsockname и shutdown;
  • Осуществлён переход на новую версию DPDK 17.11.4 LTS;
  • В состав добавлена утилита traffic для отображения текущего трафика, обрабатываемого приложениями на базе F-Stack (напоминает trafshow).

Из планов на будущее отмечается поддержка IPv6, предоставление API для языков Python, PHP и Go, поддержка API Cyptodev (Intel QAT), использование zerocopy при отправке пакетов, поддержка SPDK и возможность запуска в форме фонового процесса.

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


Обсуждение (82) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (2), 11:58, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подождите-ка, подождите-ка... Вон та верхняя картинка, с 600-байтными пакетами - там решение на F-Stack скейлится линейно с ростом нагрузки, тогда как ядерный стэк выходит на предел производительности. Это что, получается, сетевой стэк FreeBSD после трансплантации на Linux настолько уделывает родной стэк Linux'а?
     
     
  • 2.3, Аноним (3), 12:06, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Дак мы вам об этом уже 30 лет рассказываем. а вы всё трындите про свои какие-то рынки, инвестиции и тому подобный бред
     
  • 2.5, Ktoto (?), 12:17, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не забывай что ядро делает ещо кучу нужного и не очень нужного кода/логики, но ты наверное не повериш так как сильно круто любиш фрю. В итоге посмотри такиеже тесты графики но уже на родной ФРЕ.
     
     
  • 3.9, Аноним (9), 12:28, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Не забывай что ядро делает ещо кучу нужного и не очень нужного кода/логики

    Да нет, судя по графику там просто где-то что-то лочится.

     
  • 2.6, Аноним (6), 12:18, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Дело не во фряшном стеке, а в DPDK.
     
     
  • 3.34, анонн (ok), 17:04, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Дело не во фряшном стеке, а в DPDK.

    Во-во. Фряшный стек взяли чисто из соображений политкорректности, а так-то линуховый всяко дело лучше.

     
     
  • 4.90, bOOster (ok), 09:05, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В каком месте самый бестолковый стек "Всяко лучше". Когда netgraph или что-то подобное с той-же легкостью прицеплять будете вместе с "сетевым ассемблером" тогда и будете трындеть про всяко лучше. А до тех пор самый отстой что есть в сетевом opensource это linux стек IP. Этож где это видано - транспортный и прикладной уровень скриптами фильтровать! ДИКАРИ!
     
  • 2.10, Аноним (10), 12:29, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    дело не в большей производительности, а том что f-stack расположен полностью в пространстве пользователя. Это позволяет избавиться от лишних аллокаций и переключений контекста, а так как они зависят от числа пакетов, то наибольшая выгода будет достигаться в сценариях с кучей мелких пакетов. Что ты и видишь на графике.
     
  • 2.11, Аноним (11), 12:36, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я конечно не иксперд, но думаю смысл именно в том, чтоб не терять производительность между юзерспейсным приложением и сетевой картой. В обычном случае тормоза появляются от гоняния юзерспейс<->ядро. Тут же приложения смогут напрямую ломиться к утсройству без переключений контекста.
     
     
  • 3.15, Аноним (15), 13:32, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот тебе идея, как уменьшить накладные расходы на переключение контекстов Пишем... большой текст свёрнут, показать
     
     
  • 4.17, xm (ok), 13:41, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И правда, имбецилы какие-то. Особенно в сравнении с анонимами оупеннета...
     
  • 4.24, Olololo (?), 15:48, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Всё равно потребуется копирование из user space в kernel space. Избавиться от этого в принципе нельзя. В Linux kernel уже добавляли такую возможность, а потом выпили потому, что без копирования никак.
    F-Stack же не требует копирования.
     
     
  • 5.26, Olololo (?), 15:51, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дополню, там где есть копирование там есть и выделение памяти, а выделение памяти это синхронная операция.
     
  • 5.47, RibiKukan (ok), 20:55, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Здесь нету никакой проблемы копирования. Здесь мы видим убогий лям rps на полутора десятках ядер. Это обоссанных пол гига. Эти пол гига копируются 1/(50-100) секунды из/в память. Т.е. отсутствие копирование даст тебе 1% производительности. Слишком малая пропускная способность для того, что-бы копирования памяти на что-то кардинально влияло.

    Если там у тебя будет не убогих 5 гигабит, а в 10-100 раз больше - тогда профит уже будет заметен.

     
     
  • 6.57, Ivan_83 (ok), 21:50, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дело не в чистом копировании, а в том что на каждый send() дёргается сискол, который переключает контекст и делает ещё пачку проверок.
     
     
  • 7.65, Император Интернета (?), 22:25, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Про накладные расходы на сискол даже школьнику известно. А вот про то, что все пакеты которые нужно отправить нужно скопировать в kernel space почему-то не часто задумываются. Сисколы можно дёргать параллельно, а память выделять для копирования можно только синхронно. Короче, учи мат.часть.
     
     
  • 8.81, Ivan_83 (ok), 23:46, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Сам учи Я zerocopy для отправки уже лет 5 юзаю, с момента выхода FreeBSD 10 Та... текст свёрнут, показать
     
  • 8.94, Анонимус2 (?), 10:44, 20/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У вас какая-то альтернативная память, раз её нельзя выделять параллельно ... текст свёрнут, показать
     
  • 5.56, Ivan_83 (ok), 21:48, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не потребуется.
    Достаточно смапить память через mmap(), я сам так делал когда то для одной кастомной железки.
     
     
  • 6.66, Император Интернета (?), 22:28, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ты наверно виндузятник или просто ламер.
    Через mmap нельзя отобразить пакеты в кернел спейс, в кернел спейс нужно обязательно копировать т.к. есть неоднократно проверенный креш, при определённых условиях.
     
     
  • 7.79, Ivan_83 (ok), 23:43, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум слать можно без копирования через sendfile() из смапленного в память файла.

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

     
  • 4.43, RibiKukan (ok), 20:11, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я тебе отвечу почему - потому что обезьяне нужны говносокеты. И в этом проблема. А сделать нормальное api не проблема. Просто кто его юзать будет?
     
  • 4.44, Ordu (ok), 20:17, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Каким дураком надо быть, чтобы писать ядерный код там, где можно обойтись юзерсп... большой текст свёрнут, показать
     
     
  • 5.45, Император Интернета (?), 20:22, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Каким дураком надо быть, чтобы писать ядерный код там, где можно обойтись юзерспейсным?

    Обязательно сообщи это вот этим ребятам tempesta-tech.com

     
     
  • 6.48, Аноним (48), 21:08, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Общались с этими ребятами. Ну как бы так - уровень их специалистов не очень впечатлил, явно пытались хвататься за контракты не имея полных знаний о предметной области.

    Кроме того - ребята открыли для себя socket filter из FreeBSD и теперь пиарятся этим знанием.

     
     
  • 7.53, Император Интернета (?), 21:18, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Просто интересно, socket filter из FreeBSD чем-то отличаются от такого же из Linux?
     
     
  • 8.59, Ivan_83 (ok), 21:54, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да В фре их два - умеет ждать пока всё тело http запроса придёт, те до crlfcrl... текст свёрнут, показать
     
     
  • 9.74, Аноним (48), 23:18, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    главное позволяет сразу прочитать за sys call весь HTTP запрос Ну еще есть хоро... текст свёрнут, показать
     
     
  • 10.82, Ivan_83 (ok), 23:48, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да у фряхи под ядро кодить - сплошное удовольствие, там можно и своих ядерных мо... текст свёрнут, показать
     
  • 5.46, RibiKukan (ok), 20:48, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема там не в самом стеке, а в api на говносокетах Если просто У тебя есть... большой текст свёрнут, показать
     
     
  • 6.49, Аноним (48), 21:10, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    z-copy вроде Линукс научился? или это опять только в FreeBSD ?
     
     
  • 7.51, Olololo (?), 21:13, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Уже была в ядре такая штука, но её выпилил в версии 3.15 или типа того. Нельзя сделать для Linux zero copy из user space в kernel space.
     
  • 6.50, Olololo (?), 21:11, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Как интересно, выше ты пишешь, что нет никакой проблемы в копировании, а тут пишешь - "главное то, что у меня вместо тысяч сисколов и копирований будут десятки". Выше тебе уже пояснили, что копирование это есть выделение памяти, синхронная операция и т.д. и т.п. Но написав это ты сам себе противоречишь.
    Что это с тобой, шизофрения?
     
  • 6.52, Crazy Alex (ok), 21:13, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Смысл понятен, но ты хоть сравни - когда веб появился, а когда сокеты.
     
     
  • 7.93, eee (??), 16:42, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Согласно царю, всмемирное общество хттп-раст-скрипт-макак отправило агентов в прошлое, чтобы изобрести TCP и сокеты. А вообще, смысл с ним разговаривать, он же поехавший и не умеет в причинно-следственные связи.
     
  • 6.62, Аноним (62), 22:01, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но зачем? Неужели нельзя просто взять и запилить новое API, без сокетов, исключительно через отображения в память, при этом разбирать пакеты по приложениям по-прежнему в ядре?
     
     
  • 7.64, RibiKukan (ok), 22:11, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так и нужно делать и даже написал это. Но у тебя есть миллионы обезьян, которые хотят и могут только жрать говно. Куда ты их денешь? Именно из-за них мы и живём в говне. Сектанты орут "хттп - круто", "говноскрипты - круто" и прочую чушь. Среди этих убогих мы и живём, но откуда нам взять столько сортиров? Ведь если завтра мы выкинем сокеты, хттп, говноскрипту, tcp и прочий мусор - все эти поломои пойдут на туда, к чему их привала природа - мыть сортиры/полы.

    К тому же, эта поделка и базируется на подобном api.

     
     
  • 8.96, sena (ok), 17:46, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только не надо Нет никакой проблемы иметь сбоку сокет интерфейс, который бу... текст свёрнут, показать
     
  • 5.83, zzz (??), 00:16, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Зачем эти сложности, если сразу можно вынести TCP/IP стек в юзерспейс?

    Позвольте, в чем глубокий смысл этой процедуры (кроме, разве что, легкости доступа к потрохам), чтобы выносить TCP/IP в юзерспейс? Процессору всё равно, какой код молотить - ядерный или юзерспейсный, и если в юзерспейсе реализовать все те же функции, что и в ядре, мы получим точно такую же производительность, что и в ядре.

    Легкость "подкручивания" - согласен. Но часто ли надо "подкручивать" TCP/IP?

    Вы говорите "оверинжиниринг", но полноценная юзерспейсная реализация TCP/IP будет точно таким же оверинжинирингом. От того, что вы вынесете код в юзерспейс, он не станет внезапно простым и лаконичным.

     
     
  • 6.85, Ordu (ok), 00:47, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что вопрос немного в другом выбор не между выносить TCP IP в юзерспейс и... большой текст свёрнут, показать
     
     
  • 7.91, zzz (??), 11:44, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вынесете вы TCP IP в юзерспейс - сисколы к ядру от этого магическим образом н... большой текст свёрнут, показать
     
     
  • 8.92, Ordu (ok), 13:56, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Количество сисколлов уменьшится, причём вовсе не магическим образом Нет, на пра... большой текст свёрнут, показать
     
  • 2.13, xm (ok), 13:00, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Помнится несколько лет назад в Facebook была вакансия системного разработчика Linux с хорошим знанием FreeBSD и в качестве целей его найма прямо в объявлении значилось "сделать сетевой стек Linux таким же хорошим, как во FreeBSD".
    Как видно, китайские товарищи, отчаявишись, пошли путём его переноса в userspace... :-)
     
     
  • 3.18, zzz (??), 13:48, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага, было такое: https://bsd-beta.slashdot.org/story/14/08/06/1731218/facebook-seeks-devs-to-ma

     
  • 3.25, Olololo (?), 15:50, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На счёт сетевого стека все претензии тому чуваку из параллельс который написал реализацию TCP/IP
     
     
  • 4.37, zzz (??), 18:20, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А как же огромное комьюнити и вливающие миллиардами корпорации?
     
     
  • 5.40, Аноним (40), 18:52, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хотел напомнить про рсапил, который придумали далеко не у нас,
    но так вливают то - похоже за дыры, в каком нибудь TCP-IP,
    а не за их устранение и тем более оптимизации
     
  • 4.60, Ivan_83 (ok), 21:57, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там нетфликс давно уже поперписал.
     

  • 1.4, Аноним (4), 12:12, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Есть аналогичный порт линукс стека на dpdk и он также уделывает стек в ОС. И есть еще коммерческие стеки под DPDK, которые в свою очередь серьезно уделывают эти порты с FreeBSD или Linux.
     
     
  • 2.19, zzz (??), 13:52, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    И чего только китайцы потащили бсдшный стек в линукс, если линуксовый стек в dpdk и так торт. Наверное, фрибсд фаундейшн приплатила. Как уже когда-то майкрософту.
     
     
  • 3.32, Crazy Alex (ok), 16:45, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вполне могли потому и потащить, чтобы в своём юзерспейсном софте иметь BSD-лицензию. Корпорасты GPL боятся когда надо и когда не надо
     
     
  • 4.35, анонн (ok), 17:13, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вполне могли потому и потащить, чтобы в своём юзерспейсном софте иметь BSD-лицензию.
    > Корпорасты GPL боятся когда надо и когда не надо

    https://github.com/F-Stack/f-stack/blob/dev/LICENSE
    > 1.DPDK
    > BSD 3-Clause, Copyright(c) 2010-2017 Intel Corporation.All rights reserved.

    Ой?
    > 8.Microthread framework
    > GPL-2.0, Copyright (C) 2016 THL A29 Limited, a Tencent company.All rights reserved.

     
  • 4.36, Аноним (2), 17:26, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Корпорасты GPL боятся

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

     
  • 4.38, zzz (??), 18:28, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Корпорасты GPL боятся

    А так всё славно начиналось - да мы корпорастов в стойло поставим, да мы из них все сырцы выбъем, да наш ляликс будет цвести и пахнуть.

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

     
     
  • 5.63, Аноним (62), 22:03, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё правильно делают. Ибо нефиг копирастничать.
     
     
  • 6.84, zzz (??), 00:29, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Лолшто? Корпорации написали и оплатили 90% кода ляликса, превратив в запускатор для своих программ.

    Много амазон вернул кода? Тесла? Гугл? ВМварь? БМВ? Китайцы?

     

  • 1.7, Аноним (4), 12:18, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Но все это "уделывание" происходит в рамках локальной сети/ЦОД, а в интернет рулит BBR (который недавно таки портировали в BSD) или еще лучше QUIC.
     
  • 1.8, Аноним (8), 12:23, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А потом вынесут всё ядро в юзерспейс и будет микроюзер ядро.
     
     
  • 2.28, Olololo (?), 15:52, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так ведь уже лет 5 или 10 как ядро можно запускать в user space
     
     
  • 3.30, Аноним (4), 16:02, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    можно то можно, только оно там еле шевелится
     
     
  • 4.39, fi2fi (?), 18:31, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    "еле шевелится" ???

    вообще то так работает жесткий RT на базе L4

     
     
  • 5.41, Аноним (41), 18:55, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какой он тогда RT.. да, даже просто из UserSpace/Ring3...
     
  • 5.42, Аноним (42), 19:14, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Учи матчасть. RT не обязан шевелиться быстро, он обязан шевелиться с предсказуемой скоростью.
     

  • 1.12, Аноним (12), 12:40, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >сетевое взаимодействие в приложениях, применяя вместо сетевого стека операционной системы собственный сетевой стек, функционирующий в пространстве пользователя и напрямую работающий с сетевым оборудованием.

    Так это что получается, приложение должно от рута исполняться, чтобы иметь доступ к регистрам сетевой карты?

     
     
  • 2.29, Olololo (?), 15:56, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет, там требуется разрешение которое есть только у root. Root может дать эту привелегию любой учётке и эта превелигированная учётка будет иметь право использовать raw sockets, но в остальном она будет такой же не превелигированной учёткой, как и остальные юзеры.
     

  • 1.14, Ann None (?), 13:22, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    дада, раз мы не умеем openvpn и прочие xlat в ядро... мы захр^W сделаем сетевой стек в юзерспейс. а ну навались!!!
     
  • 1.16, Аноним (16), 13:33, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    в systemd еще не запихнули ?
     
     
  • 2.27, Barmaglot (??), 15:51, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное единственное полезное что можно добавить в этого монстра ... Userspace.kerneld ...
     

  • 1.20, Аноним (20), 13:54, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто то может пояснить как DPDK работает с железом в обход ядра?
     
     
  • 2.21, Аноним (21), 14:10, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Регистры железа мапятся в адресное пространство процесса.
     
  • 2.23, Аноним (48), 15:31, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в ядре выполняется мини модуль - который представляет user land доступ к некоторому ring buffer.
    + события.
    Этот ring - доступен как hugepages для всех - что уменьшает количество страниц требуемых для работы большими объемами данных.
     
     
  • 3.70, GentooBoy (ok), 22:55, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Предоставлять доступ к адресному пространству ядра или работать из ядра с памятью в пространстве пользователя плохая практика, может грозить проблемами с безопастностью
     
     
  • 4.75, Аноним (48), 23:22, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вам шашечки или ехать?

    можно тупить пытаясь пропихать кучу трафика через page cache, а можно использовать раз выделенные буфера замасленные в userspace и иметь z-copy. Второй подход дает пропускную раз в 10-15 выше.

    Так что вы уж решите что вам подходит.. хотя для админов Localhost это наверно не важно.

     
  • 4.87, Клапауций (ok), 03:54, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Предоставлять доступ к адресному пространству ядра или работать из ядра с памятью в пространстве
    > пользователя плохая практика, может грозить проблемами с безопастностью

    А оно не делает ни того, ни другого, вообще-то. DPDK обычно запирает PCI, и не только, устройства за IOMMU посредством VFIO, так что никакое ядро в память пользователя не лезет, как и сам процесс в адресное пространство ядра. Один из немногих опциональных сервисов, который ядро предлагает DPDK процессу после того, как всё сконфигурировалось - это сообщать о прерываниях, генерируемых устройством для нечастых событий, типа link down/up.

     
     
  • 5.89, Аноним (48), 06:57, 19/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    посмотри плиз что такое VFIO - и посмотри как huge pages мапятся в дескрипторы у сетевухи (hint - то что там называют PMD - не является полным драйвером).
     
     
  • 6.95, Клапауций (ok), 02:20, 21/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > посмотри плиз что такое VFIO - и посмотри как huge pages мапятся
    > в дескрипторы у сетевухи (hint - то что там называют PMD
    > - не является полным драйвером).

    Откройте сокровенное знание, что есть полный драйвер? А то я, написав несколько PMD для наших железок, в недоумении. По моему скромному разумению, то, что называетcя PMD - это именно полный драйвер для управления устройством. Кто-то его, собственно, обязан инициализировать и дёргать, это код в процессе, использующем DPDK и слинкованом с DPDK библиотеками, таком как VPP, F-Stack или какого-то из примеров. Принимает он, понимаете, пакетики из RX rings, запихивает их в TX rings, получает TX status обратно, обрабатывает link status-ы - какой магической субстанции ему не хватает для полноценности в глазах Анонима?

    Насчёт как hugepages мапятся в дескрипторы я как бы знаю, сдаётся, как минимум не хуже вас, и у меня для вас сюрприз - точно так же, как и я ядре, с той только разницей, а что собственно выступает в качестве DMA адреса (IOVA). Обычно это либо либо собственно физический адрес (PHYS), либо вообше virtual address в процессе (VA) - это уж зависит от какой IOMMU, и какой режим поддерживается UIO драйвером, что диктует, как соответствующие области памяти процесса будут прописаны в IOMMU, и будет ли IOMMU использоваться вообще. Из предлагаемых vfio-pci, vfio-dpaa[2], uio_pci_generic и uio_idb все чуток разнятся. К примеру, прокси MSI и MSI-X прерываний поддерживает только vfio-pci, а uio_igb и uio_pci_generic могут только в INTx. Режим IOVA == VA могут только vfio-{dpaa2,vpp}, если IOMMU не выключен специально.

    Учитывая вышесказанное, таки поделитесь, в какую область DPDK процесса лезет ядро, и в какую область ядра может несанционированно пробраться коварный DPDK process? Плиз.


     

  • 1.22, анонимно (?), 15:20, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Звучитит так что хотят сделать ненужными асики...
     
  • 1.31, Аноним (4), 16:10, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не поддержки IPv6 и однопоточный. Это точно порт с FreeBSD ? :)
     
     
  • 2.33, Ann None (?), 16:49, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/F-Stack/f-stack/tree/dev/freebsd/netinet6
    а это что?
     

  • 1.69, GentooBoy (ok), 22:51, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Давно не видел пакетов по 600 байт, типовая страница весит пару метров.
    А вот для mqtt  да вполне может быть.
     
     
  • 2.72, xm (ok), 23:04, 18/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну главный продукт у Tencent это QQ...
     

  • 1.97, Аноним (97), 19:01, 28/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я не могу заставить его работать, может быть вы мне поможете include stdlib... большой текст свёрнут, показать
     

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



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

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