LINUX.ORG.RU

Состоялся релиз F-Stack 1.13

 , f-stack, , ,

Состоялся релиз F-Stack 1.13

2

3

Компания Tencent выпустила новую версию F-Stack 1.13, фреймворка на базе DPDK и TCP/IP стека FreeBSD. Основной платформой для фреймворка является Linux. Код распространяется под лицензией BSD.

Фреймворк позволяет приложениям отказаться от стека операционной системы и вместо этого использовать стек, реализованный в пространстве пользователя и работающий напрямую с сетевым оборудованием.

Из заявленных особенностей фреймворка:

  • Полная загрузка сетевых карт: были достигнуты 10 млн активных сетевых подключений, 5 млн RPS и 1 млн CPS
  • Перенос стека пространства пользователя из FreeBSD 11 с удалением большого количества несущественных возможностей, что значительно повысило сетевую производительность
  • Поддержка Nginx, Redis. Другие приложения также могут использовать F-Stack
  • Легкость расширения за счет мультипроцессной архитектуры
  • Обеспечивает поддержку микропотоков. Различные приложения могут использовать F-Stack для повышения производительности без реализации сложной асинхронной логики
  • Поддерживаются стандартные API epoll/kqueue

В новой версии:

  • Добавлены интерфейсы ff_dup, ff_dup2, ff_ioctl_freebsd, ff_getsockopt_freebsd, ff_setsockopt_freebsd
  • Добавлен параметр «idle_sleep», позволяющий снизить использование процессора, если отсутствуют входящие пакеты
  • Добавлена поддержка arm64
  • Добавлена поддержка Docker
  • Добавлена поддержка vlan
  • В реализации nginx для F-Stack заменены функции getpeername, getsockname, shutdown
  • DPDK обновлен до версии 17.11.4 LTS

>>> Подробности

★★

Проверено: shell-script ()
Последнее исправление: shell-script (всего исправлений: 1)

Ответ на: комментарий от deep-purple

писать в интернеты с интелевой платформы и обзывать их гаражными мастерами смишно ))))

PETER ★★
()
Ответ на: комментарий от Deleted

а хотя мб и не в ядре. в зависимостях не видать ядерных заголовков.

Deleted
()
Ответ на: комментарий от vitalif

Ты про io_uring что ли? Оно для всего, для сокетов тоже можно

Ну пока для сокетов профита особого нет, если мне память не изменяет. Вот когда можно будет sendmmsg() без сисколов делать, тогда другое дело. Это прям збс будет, если они как-нибудь смогут в strace() пробрасывать инфу о подобных вызовах.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от vitalif

В poll режиме без сисколлов можно по идее

Мне казалось, они ещё не реализовали. Хотя я на сетевые применения не смотрел.

kirk_johnson ★☆
()
Ответ на: комментарий от PETER

да! связисты - они такие, не ищут лёгких путей!

именно после знакомства TNM понимаешь почему SNMP - «simple», а после H.323 - почему с него все бегут на SIP.

mumpster ★★★★★
()
Ответ на: комментарий от Liz812

как по мне, так они изобретают велосипед ибо NIH синдром

mumpster ★★★★★
()
Ответ на: комментарий от Deleted

В ядре то оно хорошо, только nginx там всякие у тебя не в ядре и ты теряешь в производительности из-за переключения контекста.

facepalm.jpg, да переключение контекста это херня, ты больше теряешь на копировании из буфера в буфер, ну и заодно из пространства ведра в юспейс и наоборот. с стеком в юспейсе это все исчезает - поэтому и быстрее.

alwayslate ★★
()
Ответ на: комментарий от Liz812

Тогда надо сделать специальное ядро со встроенным Redis, будет еще быстрее.

крутить хипстогавно в ring 0, да любой юспейс гавно, ровно как и 90% драйверов крайне херовая затея. ring 0 в ляпихе и так перегружен.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

facepalm.jpg, да переключение контекста это херня, ты больше теряешь на копировании из буфера в буфер, ну и заодно из пространства ведра в юспейс и наоборот. с стеком в юспейсе это все исчезает - поэтому и быстрее.

Именно переключение контекста в ядро и прохождение всех общих путей в файрволле и универсальном стеке создаёт проблемы. Ради интереса попробуйте написать программу хотя бы замеряющую сколько просто context switches в секунду возможно на вашем проце при нулевой полезной нагрузке.

А насчёт копирования памяти, в проф картах (Mellanox/Solarflare) уже давно было как Zero Copy, так и Userspace Stack (тот же openonload), и в Linux тоже уже более менее стандартизуется https://www.kernel.org/doc/html/v4.15/networking/msg_zerocopy.html и https://www.iovisor.org/technology/xdp

Попробуйте через сисколлы написать сниффер на 10Gbps, даже с ZeroCopy, будет весело.

Censo
()
Ответ на: комментарий от Censo

Именно переключение контекста в ядро и прохождение всех общих путей в файрволле и универсальном стеке создаёт проблемы.

НЕТ. переключение контекста в современных cpu не занимает много времени, замерял. больше времени отжирает копирование из одного спейса в другой - и это проблема. проводил эксперимент, одно и тоже на разных IPC, в обоих требовался syscall (то есть переключение в режим ядра и обратно) и переключение контекста - тк IPC был между двумя тасками (то есть разное адресное пространство), так вот именно КОПИРОВАНИЕ было затычкой в жопе, тк в одном IPC с таска копировался в ядро, с ядра потом в другой процесс, в другом ядро мапило кусок памяти (несколько страниц) в другое пространство. Разница была огромная. Поэтому не надо мне сказок в стиле контекст свитчи все кушают, с такими то кешами, когда TLB flush случается не часто, ой как не часто.

В случае сетевого стека там вообще несколько буферов и копирования овердохера, в юспейс заголовки ip не копируются, чтоб их туда не копировать делаем буфер и … и такого дохера.

Конечно ради производительности можно все сделать в одном адресном пространстве, в ring0, где и не копировать, быть аккуратным чтоб не затереть тот же буфер случайно с заголовком и тд, mmu не нужен, оставить mpu для того чтоб хоть как то что то иногда перемапить. Только это будет гавно, тк ради производительности не будет гибкости, секурности и тд, давайте еще писать на асме tcp/ip стек, сраный http и тд. Зато никаких контекст свитчей и быстраааааа.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

переключение контекста в современных cpu не занимает много времени

не много - это сколько? какой сискол вызывался?

indie
()
Ответ на: комментарий от indie

не много - это сколько? какой сискол вызывался?

facepalm.jpg какая разница какой сисколл … ты хоть понимаешь что такое переключение контекста?

alwayslate ★★
()
Ответ на: комментарий от alwayslate

Да, знаю. Мне цифры интересны что ты там намерял. Не понятно про «не занимает много времени». Для тебя «много» - это сколько?

indie
()
Ответ на: комментарий от alwayslate

Графики смотрел ? Выигрыш в разы наблюдается на малых пакетах, что какбе намекает на то что ты не прав.

Deleted
()
Ответ на: комментарий от alwayslate

НЕТ. переключение контекста в современных cpu не занимает много времени, замерял.

Приведите ка пожалуйста ваш код и результаты замеров.

Censo
()
Ответ на: комментарий от indie

Да, знаю. Мне цифры интересны что ты там намерял. Не понятно про «не занимает много времени». Для тебя «много» - это сколько?

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

alwayslate ★★
()
Ответ на: комментарий от Deleted

Графики смотрел ? Выигрыш в разы наблюдается на малых пакетах, что какбе намекает на то что ты не прав.

спорное утверждение.

alwayslate ★★
()
Ответ на: комментарий от Censo

Приведите ка пожалуйста ваш код и результаты замеров.

померяй сам, это ты мне тут пытаешь рассказать про страшный контекст свитч - вот померяй и покажи.

alwayslate ★★
()
Ответ на: комментарий от vasya_pupkin

Микрокернел побеждает?

он давно победил. и проиграл заодно.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

померяй сам, это ты мне тут пытаешь рассказать про страшный контекст свитч - вот померяй и покажи. НЕТ. переключение контекста в современных cpu не занимает много времени, замерял.

Экспертов ЛОРа сразу видно. Мы с вами на ты не переходили, это раз. Я с userspace networking работаю с 200х, мне не нужно доказывать кому то очевидных вещей kernel bypass, это два. Замерьте еще раз и поделитесь результатами. А потом докажите как через сисколлы можно прогнать десятки миллионов QPS даже с одним байтом нагрузки. А то как-то не заметил цифр того что вы намеряли, выше уже сказали про выигрыш на малых пакетах где память, очевидно, не узкое место.

Censo
()
Последнее исправление: Censo (всего исправлений: 1)
Ответ на: комментарий от alwayslate

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

indie
()
Ответ на: комментарий от Censo

Экспертов ЛОРа сразу видно. Мы с вами на ты не переходили, это раз. Я с userspace networking работаю с 200х, мне не нужно доказывать кому то очевидных вещей kernel bypass, это два. Замерьте еще раз и поделитесь результатами. А потом докажите как через сисколлы можно прогнать десятки миллионов QPS даже с одним байтом нагрузки. А то как-то не заметил цифр того что вы намеряли, выше уже сказали про выигрыш на малых пакетах где память, очевидно, не узкое место.

сразу видно профана «я работаю с 200x» - ты тупой идиот, и с идиотами можно на ты, ты хоть понимаешь разницу между контекст свитчем и копированием данных их юзерспейса в ведро, и обратно. так вот - когда на каждый пакет ты делаешь сисколл - больше времени у тебя (и значительно), занимает не переключение контекста, а копирование из одного буфера в другой, очевидно что это не обычной memcpy - ты это то хоть понимаешь? или ты туп совсем? икспект херов - несет херню мне полную.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

Ну так про цифры ответишь?

Сколько времени тратиться на сискол?
Сколько времени тратиться на копирование?
Как ты вообще мерял копирование?

ты тупой идиот, и с идиотами можно на ты

ты телепат? грубить ты начал первый

indie
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.