The OpenNET Project / Index page

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



"Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Второй уровень иерархии тем в форуме реализован через вкладку "Показ ключевых тем".
. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..." +/
Сообщение от Аноним (15), 18-Ноя-19, 13:32 
Вот тебе идея, как уменьшить накладные расходы на переключение контекстов.

Пишем простой модуль ядра, который открывает управляющий файл в /dev/batch_net_syscall или даже /proc/batch_net_syscall и принимает запросы в пакетном режиме (это вместо нового системного вызова). При записи в файл, ядру пачками передаются запросы на сетевые чтения/запись, причем как по UDP, так и TCP в формате типа sendmmsg (или типа того, как делает Linux AIO (io_submit), который также умеет работать с сетью, но делает это синхронно, или вообще в формате io_uring, который может вообще почти без системных вызовов принимать запросы, потому что весь обмен идет через кольцевой буфер, причем в обе стороны). Далее ядерный поток разгребает все еще не выполненные до конца запросы (новые и ранее полученные). Когда какие-то запросы завершились, управляющий файл batch_net_syscall становится доступным на чтение (и при чтении сообщает, какие запросы завершились). Таким способом можно реализовать работу в том числе и в режиме proactor (возможно, только так и получится, т.е. до завершения запроса буферы с данными трогать нельзя, с ними работает ядро). В случае пакетной обработки будет одно переключение на весь пакет, в случае обмена через кольцевые буферы (один для запросов, другой для ответов), когда есть незавершенные запросы можно просто добавлять в буфер новые без переключения контекста (а если запросов нет, то и нагрузки нет никакой, а значит, накладные расходы на переключение не имеют значения).

Как думаешь, почему так никто до сих пор не сделал? Ведь решение достаточно простое (не примитивное, но очень простое). Оно нужно только тем, кому не хватает стандартной производительности и горизонтальное масштабирование плохо работает, а значит, у них хватит ресурсов для написания такого модуля ядра (повторюсь, модуль довольно простой, не надо быть экспертом в ядре Linux, хватит LDD3 и статей из интернета). Вместо этого пишут решения с дублированием сетевых драйверов и сетевого стека целиком со всеми его заморочками... Ну, в общем делают решение раз в 100 сложнее.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..., opennews, 18-Ноя-19, 11:47  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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