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 [^] [^^] [^^^] [ответить]
| +/– |
>Не забывай что ядро делает ещо кучу нужного и не очень нужного кода/логики
Да нет, судя по графику там просто где-то что-то лочится.
| |
|
|
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 Та... текст свёрнут, показать | |
|
|
|
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 и теперь пиарятся этим знанием.
| |
|
|
|
9.74, Аноним (48), 23:18, 18/11/2019 [^] [^^] [^^^] [ответить] | +/– | главное позволяет сразу прочитать за sys call весь HTTP запрос Ну еще есть хоро... текст свёрнут, показать | |
|
|
|
|
|
|
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 +/– |
Как интересно, выше ты пишешь, что нет никакой проблемы в копировании, а тут пишешь - "главное то, что у меня вместо тысяч сисколов и копирований будут десятки". Выше тебе уже пояснили, что копирование это есть выделение памяти, синхронная операция и т.д. и т.п. Но написав это ты сам себе противоречишь.
Что это с тобой, шизофрения?
| |
|
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.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,
а не за их устранение и тем более оптимизации
| |
|
|
|
|
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, используя линукс лишь как запускатор приватных программ.
| |
|
|
6.84, zzz (??), 00:29, 19/11/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Лолшто? Корпорации написали и оплатили 90% кода ляликса, превратив в запускатор для своих программ.
Много амазон вернул кода? Тесла? Гугл? ВМварь? БМВ? Китайцы?
| |
|
|
|
|
|
1.7, Аноним (4), 12:18, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Но все это "уделывание" происходит в рамках локальной сети/ЦОД, а в интернет рулит BBR (который недавно таки портировали в BSD) или еще лучше QUIC.
| |
|
|
|
4.39, fi2fi (?), 18:31, 18/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
"еле шевелится" ???
вообще то так работает жесткий RT на базе L4
| |
|
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 сделаем сетевой стек в юзерспейс. а ну навались!!!
| |
|
2.27, Barmaglot (??), 15:51, 18/11/2019 [^] [^^] [^^^] [ответить]
| +/– |
Наверное единственное полезное что можно добавить в этого монстра ... Userspace.kerneld ...
| |
|
|
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.69, GentooBoy (ok), 22:51, 18/11/2019 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Давно не видел пакетов по 600 байт, типовая страница весит пару метров.
А вот для mqtt да вполне может быть.
| |
|