Для рассмотрения разработчиками ядра Linux представлен (https://lkml.org/lkml/2015/3/24/254) набор патчей (https://github.com/libos-nuse/net-next-nuse) с реализацией технологии LibOS (http://libos-nuse.github.io/) для Linux. Суть LibOS сводится к возможности сборки сетевого стека ядра в форме внешней разделяемой библиотеки, выполняемой в пространстве пользователя и связываемой с пользовательскими приложениями. Важной особенностью, является то, что в библиотеку выносится штатный сетевой стек ядра, что позволяет использовать такие возможности, как TCP, UDP, SCTP, DCCP,
Mobie IPv6, Multipath TCP и netlink.Подобный подход позволяет подключать к разным приложениями персонализированные варианты полноценного сетевого стека, адаптированные для конкретной области применения. Для разработчиков ядра поддержка LibOS позволит упростить тестирования кода сетевого стека при разных сценариях использования. Из интересных особенностей LibOS отмечается возможность привязки к одному приложению нескольких экземпляров сетевого стека, что даёт возможность симулировать на одной системе разные сложные сетевые топологии.
В текущем виде LibOS сосредоточен на сетевом стеке, но теоретически архитектура LibOS позволяет виртуализировать и другие подсистемы. Для управления работой вынесенного в библиотеку сетевого стека предоставляется специальный
набор утилит (https://github.com/libos-nuse/linux-libos-tools). Например, можно назначить каждому экземпляру свои сетевые интерфейсы и маршрутизацию. Связываемые с библиотекой приложения не требуют модификации и работают по аналогии с обычным сетевым стеком, для чего применяется специальный транслятор системных вызовов (связанные с сокетами символы заменяются на локальные вызовы LibOS).<center><iframe src="//www.slideshare.net/slideshow/embed_code/44752487" width="595" height="485" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" style="border:1px solid #CCC; border-width:1px; margin-bottom:5px; max-width: 100%;" allowfullscreen> </iframe></center>
URL: https://lkml.org/lkml/2015/3/24/254
Новость: http://www.opennet.ru/opennews/art.shtml?num=41904
Теперь сеть будет тормозить не меньше, чем графика, ура!
Графика давно уже не тормозит. Вон с той же макос процентов на 30%. Нехило так.
Да, халтурные порты игр с вантуза конечно есть. И это надо отличать вообще-то.Кстати, чем сабж вам не микро-ядро?
Зыж
для тестов просто сказка.
А для современных аппаратных гигабитов, когда на выходе всё-равно мега-биты, вообще красота.
> Кстати, чем сабж вам не микро-ядро?Тем, что не микро. А вот за гибридное сойдёт.
Точно.
Как и любое другое микро-ядро.
> А для современных аппаратных гигабитов, когда на выходе всё-равно мега-битыЕсть довольно много карточек 10GE+ с разгружалками, где как раз пишут юзерспейсные драйверы ради того, чтоб не щёлкать контекстами, гоняя данные из софтов в ядро...
> юзерспейсные драйверыЮзерспейсный сетевой код.
После изобретения NETMAP странно утаскивать что-то аппаратно-зависимое в Userland, проще при старте приложения попросить NETMAP замапить сетевые буферы контроллера в память процесса, откуда и разгребать.
Не тормозит? У меня отрисовка в гноме например намного медленнее чем в винде, да и почти везде в Линуксе отрисовка как я понимаю....
Графика в linux давно в ядре, подсистемы drm, ttm.
О сколько нам открытий чудных
Готовят просвещенья дух
И опыт, сын ошибок трудных,
И гений, парадоксов друг,
И случай, бог изобретатель...
(C) А. С. Пушкин
Да здравствует переключение контекста на обработку каждого транзитного пакета. Ура!Предлагаю DRM/KMS/GEM тоже реализовать в виде библиотеки. Всё ж, контекст не так часто переключаться будет, как от сетевого трафика.
в нормальных сетевках - идет прямая запись в память приложения. им не надо делать переключения..
> в нормальных сетевках - идет прямая запись в память приложения. им не
> надо делать переключения..X8-O
Это что-то новое... Для графики для таких "штук" придуман DRM (часть его -- Generic DMA Engine), а для сети что?
> X8-O
> Это что-то новое...
>, а для сети что?Сетевой ресурс LWN.net сообщает:
""Zero-copy networking will be in 2.4.4. This patch, by David Miller, Alexey Kuznetsov, and others, has been in development and testing for some time, and was incorporated into the "ac" kernel series back in 2.4.2ac4. In a way, it is a surprising change to see in a stable kernel series, since it makes fundamental changes deep in the networking code. From all reports, however, it is solid, and, in certain situations, it should produce significant performance benefits. -- http://lwn.net/2001/0419/kernel.php3
> в нормальных сетевках - идет прямая запись в память приложения. им не надо делать переключения.."Нормальным сетевкам" без разницы куда записывать, т.к. они пишут в физическую память а не в виртуальную.
А вот для того чтобы память для буферов выделялась именно из приложения а не из ядра и нужен Subj, JunOS, NETMAP, DPDK, DNA и т.д.
Сначала отколупают от ядра, а потом запхнут все это в сыстемдэ.
А потом прямо в проц!
А что мешает все драйвера запилить на скриптовых ЯП и подлючать через интерфейс в ядро?
> А что мешает все драйвера запилить на скриптовых ЯП и подлючать через
> интерфейс в ядро?Да в принципе можно конечно и бегать по потолку, надев ласты и противогаз. Но зачем?
Нужно. Бывают ситуации, когда нужно собирать минималистичное ядро без поддержки сети. Этот проект поможет основному ядру не ломать такую возможность - а то отключить как бы и можно, но как бы и нет. Это как работать в KDE4 без мышки.
В каком это таком эмбеде может понадобиться linux без сети? Разве что на пылесосе или кофемашине - но там это уже головные боли разработчиков, пусть курят LFS.
Опять же, если ресурсов побольше, чем на быт. технике, то почему нельзя портировать фряшную VImage?
Да жесть, то dbus в ядро чтобы задержки убрать , то сеть из ядра ради каких-то там каличей, порою смотришь как люди носят кепки - козырьком и вперед, и назад, и вбок, и думаешь, ладно хоть на машинах штатно задом не ездят, а теперь вот хз может и начнут.
Имеет место сказать, что предпринимаются глуповатые
попытки что-нибудь привнести нового, граничащего
с бесполезным.Хотя с другой стороны, если ядро главный модуль,
то то, что неявляется по существу сервисом ядра,
вынести в отдельный модуль...Я не силен архитектуре ядра, но это помоему, такие
начальные попытки плавного перехода к микроядру...Как то так.
Нее, микроядер хватает, микроядра работают через шину, которая в линухе только только появилась, скорее квантовый компьютер появится в каждом доме, чем линух эволюционирует до микроядра.
Кепку носить козырьком назад вполне обоснованно - козырек сужает видимую область окружающего мира, а нужен только в солнечную погоду.
> Кепку носить козырьком назад вполне обоснованно - козырек сужает видимую область окружающего мира, а нужен только в солнечную погоду.Ну по анекдоту же! козырек назад - чтоб дождевая вода за шиворот не текла. А козырьки по бокам - чтоб лапшу на уши не вешали!
Смотри сюда. Если объяснять упрощенно, тоDBus:
Юзерспейс - приложение -> ядро (unix socket) -> dbus-daemon -> ядро (unix socket) -> приложение
Кернелспейс - приложение -> ядро (dbus-daemon) -> приложениеОчевидный профит
Сетевой стек:
Кернелспейс - сетевая карта -> ядро (сетевой стек) -> приложение (сетевой стек) -> ядро (сетевой стек) -> сетевая карта
Юзерспейс - сетевая карта -> приложение (сетевой стек) -> сетевая картаОчевидный профит
Ну если ещё сделают, что эта LibOS будет способна собираться для работы поверх маленьких RT-ядер для микроконтроллеров, типа этого http://chibios.org/, то - польза.
А если запихнуть в неё ещё и netfilter и заставить работать поверх NT-шного ядра, то для офтопика появится полностью контролируемый пользователем гибкий файервол.
> для офтопикаМиниатюра "амбарная дверь с пудовым замком в пустыне".
wipfw
LwIP
ucLinux
> wipfwпропускает. доказано.
uIP (предшественник lwIP)
Больше троянов, хороших и нужных.
зачем клоунаду разводить не пролистав презентацию?Производительность у NUSE хуже (всегда будет хуже).
Из плюсов - можно тестировать разные топологии, прогонять код под valgrind и gdb, проверять покрытие кода тестами. Например, сколько багов нашли и ещё находят в реализации SCTP ?Если брать mTCP (который уже давно не новый:
так он решает свою задачу: предоставить высокую производительность для одного приложения (например для lighttpd кроме которого на сервере ничего нет) для 10Gbit Ethernet и быстрее
http://shader.kaist.edu/mtcp/
http://www.ndsl.kaist.edu/~kyoungsoo/papers/mtcp.pdfКакие сейчас проблемы с текущим сетевым стеком можно посмотреть:
https://lwn.net/Articles/629155/
>В текущем виде LibOS сосредоточен на сетевом стеке, но теоретически архитектура LibOS позволяет виртуализировать и другие подсистемы.это ж по-сути намек на микроядро (или гибрид). Не Танненбаума ли это казачки?
Да нее, это реализация вот этого https://ru.wikipedia.org/wiki/%D0%AD%D0%...A long, long time ago...
Даешь подключение сетевого стека по сети!
> Даешь подключение сетевого стека по сети!man pxe
Но только после того, как выучишь уроки!
Вспомнили net-server BeOS ? ;-)))