Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..., opennews (??), 18-Ноя-19, (0) [смотреть все] Подождите-ка, подождите-ка Вон та верхняя картинка, с 600-байтными пакетами -, Аноним (2), 11:58 , 18-Ноя-19, (2) // Дак мы вам об этом уже 30 лет рассказываем а вы всё трындите про свои какие-то , Аноним (3), 12:06 , 18-Ноя-19, (3) +8 Не забывай что ядро делает ещо кучу нужного и не очень нужного кода логики, но т, Ktoto (?), 12:17 , 18-Ноя-19, (5) // Да нет, судя по графику там просто где-то что-то лочится , Аноним (9), 12:28 , 18-Ноя-19, (9) Дело не во фряшном стеке, а в DPDK , Аноним (6), 12:18 , 18-Ноя-19, (6) +4 // Во-во Фряшный стек взяли чисто из соображений политкорректности, а так-то линух, анонн (ok), 17:04 , 18-Ноя-19, (34) +2 // В каком месте самый бестолковый стек Всяко лучше Когда netgraph или что-то по, bOOster (ok), 09:05 , 19-Ноя-19, (90) –1 дело не в большей производительности, а том что f-stack расположен полностью в п, Аноним (10), 12:29 , 18-Ноя-19, (10) +3 Я конечно не иксперд, но думаю смысл именно в том, чтоб не терять производительн, Аноним (11), 12:36 , 18-Ноя-19, (11) +3   // Вот тебе идея, как уменьшить накладные расходы на переключение контекстов Пишем , Аноним (15), 13:32 , 18-Ноя-19, (15)   // И правда, имбецилы какие-то Особенно в сравнении с анонимами оупеннета , xm (ok), 13:41 , 18-Ноя-19, (17) –1   Всё равно потребуется копирование из user space в kernel space Избавиться от эт, Olololo (?), 15:48 , 18-Ноя-19, (24) +2   Дополню, там где есть копирование там есть и выделение памяти, а выделение памят, Olololo (?), 15:51 , 18-Ноя-19, (26) +2   Здесь нету никакой проблемы копирования Здесь мы видим убогий лям rps на полуто, RibiKukan (ok), 20:55 , 18-Ноя-19, (47)   Дело не в чистом копировании, а в том что на каждый send дёргается сискол, кот, Ivan_83 (ok), 21:50 , 18-Ноя-19, (57) +1   Про накладные расходы на сискол даже школьнику известно А вот про то, что все п, Император Интернета (?), 22:25 , 18-Ноя-19, (65) –1   Сам учи Я zerocopy для отправки уже лет 5 юзаю, с момента выхода FreeBSD 10 Там , Ivan_83 (ok), 23:46 , 18-Ноя-19, (81) +1   У вас какая-то альтернативная память, раз её нельзя выделять параллельно , Анонимус2 (?), 10:44 , 20-Ноя-19, (94)   Не потребуется Достаточно смапить память через mmap , я сам так делал когда то , Ivan_83 (ok), 21:48 , 18-Ноя-19, (56) +1   Ты наверно виндузятник или просто ламер Через mmap нельзя отобразить пакеты в ке, Император Интернета (?), 22:28 , 18-Ноя-19, (66)   Как минимум слать можно без копирования через sendfile из смапленного в память, Ivan_83 (ok), 23:43 , 18-Ноя-19, (79)   Я тебе отвечу почему - потому что обезьяне нужны говносокеты И в этом проблема , RibiKukan (ok), 20:11 , 18-Ноя-19, (43) –1   Каким дураком надо быть, чтобы писать ядерный код там, где можно обойтись юзерсп, Ordu (ok), 20:17 , 18-Ноя-19, (44)   Обязательно сообщи это вот этим ребятам tempesta-tech com, Император Интернета (?), 20:22 , 18-Ноя-19, (45) +1   Общались с этими ребятами Ну как бы так - уровень их специалистов не очень впеч, Аноним (48), 21:08 , 18-Ноя-19, (48)   Просто интересно, socket filter из FreeBSD чем-то отличаются от такого же из Lin, Император Интернета (?), 21:18 , 18-Ноя-19, (53)   Да В фре их два - умеет ждать пока всё тело http запроса придёт, те до crlfcrlf , Ivan_83 (ok), 21:54 , 18-Ноя-19, (59)   главное позволяет сразу прочитать за sys call весь HTTP запрос Ну еще есть хорош, Аноним (48), 23:18 , 18-Ноя-19, (74)   Да у фряхи под ядро кодить - сплошное удовольствие, там можно и своих ядерных мо, Ivan_83 (ok), 23:48 , 18-Ноя-19, (82)   Проблема там не в самом стеке, а в api на говносокетах Если просто У тебя есть , RibiKukan (ok), 20:48 , 18-Ноя-19, (46)   z-copy вроде Линукс научился или это опять только в FreeBSD , Аноним (48), 21:10 , 18-Ноя-19, (49)   Уже была в ядре такая штука, но её выпилил в версии 3 15 или типа того Нельзя с, Olololo (?), 21:13 , 18-Ноя-19, (51) +2   Как интересно, выше ты пишешь, что нет никакой проблемы в копировании, а тут пиш, Olololo (?), 21:11 , 18-Ноя-19, (50) +2   Смысл понятен, но ты хоть сравни - когда веб появился, а когда сокеты , Crazy Alex (ok), 21:13 , 18-Ноя-19, (52) +1   Согласно царю, всмемирное общество хттп-раст-скрипт-макак отправило агентов в пр, eee (??), 16:42 , 19-Ноя-19, (93)   Но зачем Неужели нельзя просто взять и запилить новое API, без сокетов, исключи, Аноним (62), 22:01 , 18-Ноя-19, (62) –1   Ну так и нужно делать и даже написал это Но у тебя есть миллионы обезьян, котор, RibiKukan (ok), 22:11 , 18-Ноя-19, (64)   Вот только не надо Нет никакой проблемы иметь сбоку сокет интерфейс, который бу, sena (ok), 17:46 , 21-Ноя-19, (96)   Позвольте, в чем глубокий смысл этой процедуры кроме, разве что, легкости досту, zzz (??), 00:16 , 19-Ноя-19, (83)   Потому что вопрос немного в другом выбор не между выносить TCP IP в юзерспейс и, Ordu (ok), 00:47 , 19-Ноя-19, (85)   Ну вынесете вы TCP IP в юзерспейс - сисколы к ядру от этого магическим образом н, zzz (??), 11:44 , 19-Ноя-19, (91)   Количество сисколлов уменьшится, причём вовсе не магическим образом Нет, на прак, Ordu (ok), 13:56 , 19-Ноя-19, (92)   Помнится несколько лет назад в Facebook была вакансия системного разработчика Li, xm (ok), 13:00 , 18-Ноя-19, (13) –1 // Ага, было такое https bsd-beta slashdot org story 14 08 06 1731218 facebook-s, zzz (??), 13:48 , 18-Ноя-19, (18) +1 На счёт сетевого стека все претензии тому чуваку из параллельс который написал р, Olololo (?), 15:50 , 18-Ноя-19, (25) +1 // А как же огромное комьюнити и вливающие миллиардами корпорации , zzz (??), 18:20 , 18-Ноя-19, (37) +2 Хотел напомнить про рсапил, который придумали далеко не у нас, но так вливают то, Аноним (40), 18:52 , 18-Ноя-19, (40) –1 Там нетфликс давно уже поперписал , Ivan_83 (ok), 21:57 , 18-Ноя-19, (60) Есть аналогичный порт линукс стека на dpdk и он также уделывает стек в ОС И ест, Аноним (4), 12:12 , 18-Ноя-19, (4) +3 // И чего только китайцы потащили бсдшный стек в линукс, если линуксовый стек в dpd, zzz (??), 13:52 , 18-Ноя-19, (19) –3 // Вполне могли потому и потащить, чтобы в своём юзерспейсном софте иметь BSD-лицен, Crazy Alex (ok), 16:45 , 18-Ноя-19, (32) +1 // https github com F-Stack f-stack blob dev LICENSEОй , анонн (ok), 17:13 , 18-Ноя-19, (35) +1 Ога, поэтому вложились в разработку новой приблуды для линуха , Аноним (2), 17:26 , 18-Ноя-19, (36) А так всё славно начиналось - да мы корпорастов в стойло поставим, да мы из них , zzz (??), 18:28 , 18-Ноя-19, (38) +2 Всё правильно делают Ибо нефиг копирастничать , Аноним (62), 22:03 , 18-Ноя-19, (63) –1 Лолшто Корпорации написали и оплатили 90 кода ляликса, превратив в запускатор , zzz (??), 00:29 , 19-Ноя-19, (84) +1 Но все это уделывание происходит в рамках локальной сети ЦОД, а в интернет рул, Аноним (4), 12:18 , 18-Ноя-19, (7) –1 А потом вынесут всё ядро в юзерспейс и будет микроюзер ядро , Аноним (8), 12:23 , 18-Ноя-19, (8) // Так ведь уже лет 5 или 10 как ядро можно запускать в user space, Olololo (?), 15:52 , 18-Ноя-19, (28) +1 // можно то можно, только оно там еле шевелится, Аноним (4), 16:02 , 18-Ноя-19, (30) // еле шевелится вообще то так работает жесткий RT на базе L4, fi2fi (?), 18:31 , 18-Ноя-19, (39) Какой он тогда RT да, даже просто из UserSpace Ring3 , Аноним (41), 18:55 , 18-Ноя-19, (41) –1 Учи матчасть RT не обязан шевелиться быстро, он обязан шевелиться с предсказуем, Аноним (42), 19:14 , 18-Ноя-19, (42) +2 Так это что получается, приложение должно от рута исполняться, чтобы иметь досту, Аноним (12), 12:40 , 18-Ноя-19, (12) +1 // Нет, там требуется разрешение которое есть только у root Root может дать эту пр, Olololo (?), 15:56 , 18-Ноя-19, (29) +2 дада, раз мы не умеем openvpn и прочие xlat в ядро мы захр W сделаем сетевой , Ann None (?), 13:22 , 18-Ноя-19, (14) в systemd еще не запихнули , Аноним (16), 13:33 , 18-Ноя-19, (16) +1 // Наверное единственное полезное что можно добавить в этого монстра Userspace , Barmaglot (??), 15:51 , 18-Ноя-19, (27) Кто то может пояснить как DPDK работает с железом в обход ядра , Аноним (20), 13:54 , 18-Ноя-19, (20) +1 // Регистры железа мапятся в адресное пространство процесса , Аноним (21), 14:10 , 18-Ноя-19, (21) +1 в ядре выполняется мини модуль - который представляет user land доступ к некотор, Аноним (48), 15:31 , 18-Ноя-19, (23) +1 // Предоставлять доступ к адресному пространству ядра или работать из ядра с память, GentooBoy (ok), 22:55 , 18-Ноя-19, (70) // вам шашечки или ехать можно тупить пытаясь пропихать кучу трафика через page cac, Аноним (48), 23:22 , 18-Ноя-19, (75) А оно не делает ни того, ни другого, вообще-то DPDK обычно запирает PCI, и не т, Клапауций (ok), 03:54 , 19-Ноя-19, (87) посмотри плиз что такое VFIO - и посмотри как huge pages мапятся в дескрипторы у, Аноним (48), 06:57 , 19-Ноя-19, (89) Откройте сокровенное знание, что есть полный драйвер А то я, написав несколько , Клапауций (ok), 02:20 , 21-Ноя-19, (95) Звучитит так что хотят сделать ненужными асики , анонимно (?), 15:20 , 18-Ноя-19, (22) Не поддержки IPv6 и однопоточный Это точно порт с FreeBSD , Аноним (4), 16:10 , 18-Ноя-19, (31) // https github com F-Stack f-stack tree dev freebsd netinet6а это что , Ann None (?), 16:49 , 18-Ноя-19, (33) Давно не видел пакетов по 600 байт, типовая страница весит пару метров А вот для, GentooBoy (ok), 22:51 , 18-Ноя-19, (69) // Ну главный продукт у Tencent это QQ , xm (ok), 23:04 , 18-Ноя-19, (72) я не могу заставить его работать, может быть вы мне поможете include stdlib , Аноним (97), 19:01 , 28-Ноя-19, (97) 2,4,7,8,12,14,16,20,22,31,69,97

Сообщения

[Сортировка по времени | RSS]

	11. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+3 +/–
	Сообщение от Аноним (11), 18-Ноя-19, 12:36
	Я конечно не иксперд, но думаю смысл именно в том, чтоб не терять производительность между юзерспейсным приложением и сетевой картой. В обычном случае тормоза появляются от гоняния юзерспейс<->ядро. Тут же приложения смогут напрямую ломиться к утсройству без переключений контекста.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	15. "Выпуск сетевого стека 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ообщить модератору

	17. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	–1 +/–
	Сообщение от xm (ok), 18-Ноя-19, 13:41
	И правда, имбецилы какие-то. Особенно в сравнении с анонимами оупеннета...
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+2 +/–
	Сообщение от Olololo (?), 18-Ноя-19, 15:48
	Всё равно потребуется копирование из user space в kernel space. Избавиться от этого в принципе нельзя. В Linux kernel уже добавляли такую возможность, а потом выпили потому, что без копирования никак. F-Stack же не требует копирования.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	26. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+2 +/–
	Сообщение от Olololo (?), 18-Ноя-19, 15:51
	Дополню, там где есть копирование там есть и выделение памяти, а выделение памяти это синхронная операция.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от RibiKukan (ok), 18-Ноя-19, 20:55
	Здесь нету никакой проблемы копирования. Здесь мы видим убогий лям rps на полутора десятках ядер. Это обоссанных пол гига. Эти пол гига копируются 1/(50-100) секунды из/в память. Т.е. отсутствие копирование даст тебе 1% производительности. Слишком малая пропускная способность для того, что-бы копирования памяти на что-то кардинально влияло. Если там у тебя будет не убогих 5 гигабит, а в 10-100 раз больше - тогда профит уже будет заметен.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	57. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+1 +/–
	Сообщение от Ivan_83 (ok), 18-Ноя-19, 21:50
	Дело не в чистом копировании, а в том что на каждый send() дёргается сискол, который переключает контекст и делает ещё пачку проверок.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	–1 +/–
	Сообщение от Император Интернета (?), 18-Ноя-19, 22:25
	Про накладные расходы на сискол даже школьнику известно. А вот про то, что все пакеты которые нужно отправить нужно скопировать в kernel space почему-то не часто задумываются. Сисколы можно дёргать параллельно, а память выделять для копирования можно только синхронно. Короче, учи мат.часть.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+1 +/–
	Сообщение от Ivan_83 (ok), 18-Ноя-19, 23:46
	Сам учи. Я zerocopy для отправки уже лет 5 юзаю, с момента выхода FreeBSD 10. Там сделали так что shm можно делать полностью смапленый в память, но получать файловый дескриптор годный для передачи в sendfile(). У меня msd так работает: у него кольцевой буфер где лежит принятый TS поток лежит как раз в такой смапленой памяти, и когда кому то надо послать очередную порцию то дёргается sendfile() с нужным оффсетом и размером. И реально никаких копирований нет, ну кроме тех аргументов что в sendfile() передаются, что просто не существенно. В линуксах вроде аналогично, но делается файл в tmpfs.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Анонимус2 (?), 20-Ноя-19, 10:44
	У вас какая-то альтернативная память, раз её нельзя выделять параллельно.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	56. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+1 +/–
	Сообщение от Ivan_83 (ok), 18-Ноя-19, 21:48
	Не потребуется. Достаточно смапить память через mmap(), я сам так делал когда то для одной кастомной железки.
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	66. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Император Интернета (?), 18-Ноя-19, 22:28
	Ты наверно виндузятник или просто ламер. Через mmap нельзя отобразить пакеты в кернел спейс, в кернел спейс нужно обязательно копировать т.к. есть неоднократно проверенный креш, при определённых условиях.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Ivan_83 (ok), 18-Ноя-19, 23:43
	Как минимум слать можно без копирования через sendfile() из смапленного в память файла. Да, копировать наверное в большинстве случаев при приёме необходимо, но не из за крешей а из за того что требуется отрезать заголовки, делать дефрагментацию и тп.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	–1 +/–
	Сообщение от RibiKukan (ok), 18-Ноя-19, 20:11
	Я тебе отвечу почему - потому что обезьяне нужны говносокеты. И в этом проблема. А сделать нормальное api не проблема. Просто кто его юзать будет?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	44. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Ordu (ok), 18-Ноя-19, 20:17
	> Как думаешь, почему так никто до сих пор не сделал? Ведь решение достаточно простое (не примитивное, но очень простое). Каким дураком надо быть, чтобы писать ядерный код там, где можно обойтись юзерспейсным? То есть, если бы всё было так просто, как ты описываешь, может быть в этом и имелся бы смысл, но в реальности ведь получится обычная задница: мы напишем модуль, пропишем протокол общения между модулем и юзерспейсом, но на следующей же день выяснится, что протокол не позволяет что-то там сделать эффективно. Мы изменим протокол допишем модуль. Через неделю ещё раз. Потом ещё. Ещё. И ещё. И так это будет продолжаться до тех пор, пока этот модуль не превратиться в кусок оверинжиниринга переплетённый с обратной совместимостью (потому что мы не каждый раз переписывали модуль, когда в этом возникала необходимость, лишь тогда когда не было возможности этого избежать посредством юзерспейсных костылей). Потом, подумав, мы добавим в ядро интерпретатор байткода, чтобы мы могли бы грузить в ядро процедурки, управляющие обработкой трафика. А потом всё наше приложение окажется в ядерном адресном пространстве. И ядро превратиться в дуршлаг. И вот тут, мы подумаем и вынесем стек TCP/IP в юзерспейс, оставив в ядре только самое необходимое. Зачем эти сложности, если сразу можно вынести TCP/IP стек в юзерспейс?
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	45. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+1 +/–
	Сообщение от Император Интернета (?), 18-Ноя-19, 20:22
	>Каким дураком надо быть, чтобы писать ядерный код там, где можно обойтись юзерспейсным? Обязательно сообщи это вот этим ребятам tempesta-tech.com
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Аноним (48), 18-Ноя-19, 21:08
	Общались с этими ребятами. Ну как бы так - уровень их специалистов не очень впечатлил, явно пытались хвататься за контракты не имея полных знаний о предметной области. Кроме того - ребята открыли для себя socket filter из FreeBSD и теперь пиарятся этим знанием.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Император Интернета (?), 18-Ноя-19, 21:18
	Просто интересно, socket filter из FreeBSD чем-то отличаются от такого же из Linux?
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Ivan_83 (ok), 18-Ноя-19, 21:54
	Да. В фре их два: - умеет ждать пока всё тело http запроса придёт, те до crlfcrlf и тольпо после сокет уходит в accept - тоже самое только для полного dns запроса В линуксе фильтр просто ждёт пока не придёт n байт.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Аноним (48), 18-Ноя-19, 23:18
	главное позволяет сразу прочитать за sys call весь HTTP запрос. Ну еще есть хороший API который позволяет из модуля дописать свой фильтр.. Чего Linux предоставить не может.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Ivan_83 (ok), 18-Ноя-19, 23:48
	Да у фряхи под ядро кодить - сплошное удовольствие, там можно и своих ядерных модулей понаписать.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от RibiKukan (ok), 18-Ноя-19, 20:48
	Проблема там не в самом стеке, а в api на говносокетах. Если просто. У тебя есть поток пакетов, которые приходят из сети. Там есть tcp-говна(протокол для веб-макак от веб-макак). Оно работает как говно, да и он и есть говно, но - не в этом проблема. Весь этот поток пакетов распиливается на множество уже tcp-потоков. Далее всё это говно сливается в буфера сокетов. Далее уже в юзерспейсе у тебя есть идентификаторы этих сокетов, которые ты долбишь путём read/write. Проблема именно в этой долбёжки, которая происходит из юзерспейса в кернелспейс и обратно. Это не вся проблема, но наиболее заметная её часть. Что же делается тут. Поток пакетов сразу отдаётся юзерспейсу. И тут даже неважно как - главное то, что у меня вместо тысяч сисколов и копирований будут десятки. А уже далее берётся тот самый стек говна на мусорных сокетах и запускается в юзерпейсе. Он так же пилить всё это говно на тысячи потоков/сокетов и веб-говно так же общается с ним. Но теперь это происходит в юзерпейса и никакой коммуникации между ядром и юзерпейсом на каждое чтение/запись ненужно. И так же очевидно, что если выкинуть это мусорное api для веб-макак(а ещё лучше выкинуть этот протокол говна), то все проблемы уйдут сами собою. Но веб-макак тогда ничего не сможет - как же она будет без мусорных сокетов.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	49. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Аноним (48), 18-Ноя-19, 21:10
	z-copy вроде Линукс научился? или это опять только в FreeBSD ?
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+2 +/–
	Сообщение от Olololo (?), 18-Ноя-19, 21:13
	Уже была в ядре такая штука, но её выпилил в версии 3.15 или типа того. Нельзя сделать для Linux zero copy из user space в kernel space.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+2 +/–
	Сообщение от Olololo (?), 18-Ноя-19, 21:11
	Как интересно, выше ты пишешь, что нет никакой проблемы в копировании, а тут пишешь - "главное то, что у меня вместо тысяч сисколов и копирований будут десятки". Выше тебе уже пояснили, что копирование это есть выделение памяти, синхронная операция и т.д. и т.п. Но написав это ты сам себе противоречишь. Что это с тобой, шизофрения?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	52. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+1 +/–
	Сообщение от Crazy Alex (ok), 18-Ноя-19, 21:13
	Смысл понятен, но ты хоть сравни - когда веб появился, а когда сокеты.
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	93. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от eee (??), 19-Ноя-19, 16:42
	Согласно царю, всмемирное общество хттп-раст-скрипт-макак отправило агентов в прошлое, чтобы изобрести TCP и сокеты. А вообще, смысл с ним разговаривать, он же поехавший и не умеет в причинно-следственные связи.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	–1 +/–
	Сообщение от Аноним (62), 18-Ноя-19, 22:01
	Но зачем? Неужели нельзя просто взять и запилить новое API, без сокетов, исключительно через отображения в память, при этом разбирать пакеты по приложениям по-прежнему в ядре?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

	64. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от RibiKukan (ok), 18-Ноя-19, 22:11
	Ну так и нужно делать и даже написал это. Но у тебя есть миллионы обезьян, которые хотят и могут только жрать говно. Куда ты их денешь? Именно из-за них мы и живём в говне. Сектанты орут "хттп - круто", "говноскрипты - круто" и прочую чушь. Среди этих убогих мы и живём, но откуда нам взять столько сортиров? Ведь если завтра мы выкинем сокеты, хттп, говноскрипту, tcp и прочий мусор - все эти поломои пойдут на туда, к чему их привала природа - мыть сортиры/полы. К тому же, эта поделка и базируется на подобном api.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от sena (ok), 21-Ноя-19, 17:46
	> Ну так и нужно делать и даже написал это. Но у тебя есть миллионы обезьян, которые хотят и могут только жрать говно. Куда ты их денешь? Вот только не надо. Нет никакой проблемы иметь сбоку сокет интерфейс, который будет работать по старой схеме для старых приложенией.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от zzz (??), 19-Ноя-19, 00:16
	>Зачем эти сложности, если сразу можно вынести TCP/IP стек в юзерспейс? Позвольте, в чем глубокий смысл этой процедуры (кроме, разве что, легкости доступа к потрохам), чтобы выносить TCP/IP в юзерспейс? Процессору всё равно, какой код молотить - ядерный или юзерспейсный, и если в юзерспейсе реализовать все те же функции, что и в ядре, мы получим точно такую же производительность, что и в ядре. Легкость "подкручивания" - согласен. Но часто ли надо "подкручивать" TCP/IP? Вы говорите "оверинжиниринг", но полноценная юзерспейсная реализация TCP/IP будет точно таким же оверинжинирингом. От того, что вы вынесете код в юзерспейс, он не станет внезапно простым и лаконичным.
	Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

	85. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Ordu (ok), 19-Ноя-19, 00:47
	>>Зачем эти сложности, если сразу можно вынести TCP/IP стек в юзерспейс? > Позвольте, в чем глубокий смысл этой процедуры (кроме, разве что, легкости доступа > к потрохам), чтобы выносить TCP/IP в юзерспейс? Процессору всё равно, какой > код молотить - ядерный или юзерспейсный, и если в юзерспейсе реализовать > все те же функции, что и в ядре, мы получим точно > такую же производительность, что и в ядре. Потому что вопрос немного в другом: выбор не между выносить TCP/IP в юзерспейс или не выносить, выбор между засовывать ли весь код (включая сюда и http сервер) в ядро, или выносить весь код в юзерспейс. Задача стоит в том, чтобы разграничительная линия сисколлов проходила бы не между кодом http-сервера и TCP/IP стеком, а где-нибудь в другом месте, где эту линию можно будет реже пересекать. > Легкость "подкручивания" - согласен. Но часто ли надо "подкручивать" TCP/IP? TCP/IP не надо часто подкручивать, но вот реализацию TCP/IP заточенную под какие-то оптимизационные параметры и использующуюся для различных задач -- придётся. Возможно её придётся подкручивать под каждое конкретное применение. Оптимизация она такая. > Вы говорите "оверинжиниринг", но полноценная юзерспейсная реализация TCP/IP будет точно > таким же оверинжинирингом. От того, что вы вынесете код в юзерспейс, > он не станет внезапно простым и лаконичным. Оверинжиниринг -- это не просто количество кода, это скорее к тому, как много возможностей было заложено в код при проектировании, и как много из них оказалось востребовано. Дисбаланс между этими вещами либо приводит к костылестроению, вызванному тому, что библиотечный код неспособен решать задачи, которые он должен решать, либо этот дисбаланс приводит к оверинжинирингу, когда библиотечный код безумно сложен из-за того, что он рассчитан решать все задачи мира, в нём есть возможность подкрутить и настроить всё что угодно, в том числе и то, что никто никогда не подкручивает и не настраивает, но реально используется лишь часть этого. Скажем функция с двадцатью аргументами, из которых в 99 случаях из ста используются два первых, в остальные в 99 случаях передаются всякие значения типа 0, NULL, -1, nil и тп. Или безумная иерархия классов, из которых половина всегда создаётся дефолтным конструктором и никогда не меняется никем и ничем, несмотря на огромнейшие API позволяющие всё это настроить. Вынос кода в юзерспейс позволяет более интересные способы взаимодействия между библиотечным кодом и клиентским. Не только сисколлы типа read/write, но скажем, итератор -- библиотека вполне может реализовать метод next, для перебора каких-либо сущностей, и этот метод может быть даже инлайн-функцией, если это надо. Библиотека может дать доступ к своей внутренней структуре и дать мне возможность либо читать её, либо даже менять -- может быть посредством непосредственной записи в поля, может быть посредством inline акцессоров, или может быть посредством сложных функций которые выполняют сложные действия. Это всё можно в юзерспейсе, это снимает кучу ограничений с разработчиков кода, это резко упрощает им задачу, и соответственно у них гораздо больше шансов получить _простой_ код, который с одной стороны не утонет в костылях, с другой стороны не будет на 90% неиспользуемым в реальности. Простой не в смысле количества строк кода, а в смысле того сколько потребуется времени, для того чтобы разобраться в этом коде и понять как этот код надо изменить, чтобы требуемым образом изменить поведение этого кода.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от zzz (??), 19-Ноя-19, 11:44
	>Задача стоит в том, чтобы разграничительная линия сисколлов проходила бы не между кодом http-сервера и TCP/IP стеком, а где-нибудь в другом месте, где эту линию можно будет реже пересекать. Ну вынесете вы TCP/IP в юзерспейс - сисколы к ядру от этого магическим образом не исчезнут и меньше их не станет. >как много возможностей было заложено в код при проектировании, и как много из них оказалось востребовано Выше вы пишете: "на следующей же день выяснится, что протокол не позволяет что-то там сделать эффективно. Мы изменим протокол допишем модуль. Через неделю ещё раз. Потом ещё. Ещё. И ещё.". Как вы сами писали, возможности закладываются не от балды, а из-за необходимости делать что-то там эффективно, стало быть, эти функции востребованы. С другой стороны, ну хорошо: выносим TCP/IP в юзерспейс, удаляем всякое "ненужное". Всё это приведет к тому, что в юзерспейсе будет зоопарк реализаций TCP/IP разной степени кривизны вместо одной эталонной реализации. Не кажется ли вам это еще большим оверинжинирингом и распылением сил? Открытым остается и вопрос файрволинга в такой конфигурации.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Выпуск сетевого стека F-Stack 1.13,  выполняемого в простран..."	+/–
	Сообщение от Ordu (ok), 19-Ноя-19, 13:56
	>>Задача стоит в том, чтобы разграничительная линия сисколлов проходила бы не между кодом http-сервера и TCP/IP стеком, а где-нибудь в другом месте, где эту линию можно будет реже пересекать. > Ну вынесете вы TCP/IP в юзерспейс - сисколы к ядру от этого > магическим образом не исчезнут и меньше их не станет. Количество сисколлов уменьшится, причём вовсе не магическим образом. >>как много возможностей было заложено в код при проектировании, и как много из них оказалось востребовано > Выше вы пишете: "на следующей же день выяснится, что протокол не позволяет > что-то там сделать эффективно. Мы изменим протокол допишем модуль. Через неделю > ещё раз. Потом ещё. Ещё. И ещё.". Как вы сами писали, > возможности закладываются не от балды, а из-за необходимости делать что-то там > эффективно, стало быть, эти функции востребованы. Нет, на практике так бывает редко. > С другой стороны, ну хорошо: выносим TCP/IP в юзерспейс, удаляем всякое "ненужное". > Всё это приведет к тому, что в юзерспейсе будет зоопарк реализаций > TCP/IP разной степени кривизны вместо одной эталонной реализации. Не кажется ли > вам это еще большим оверинжинирингом и распылением сил? Распыление сил -- это миф. А почему это не оверинжиниринг я объяснил выше. > Открытым остается и вопрос файрволинга в такой конфигурации. Ой не знаю. Кто тебе сказал, что этот вопрос вообще стоял?
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема