kernel sendto

> мне нужно чтобы мой модуль ядра, по UDP общался с приложением

б-же, прибейте их кто-нибудь. Зачем?!!

> б-же, прибейте их кто-нибудь. Зачем?!! давйте пожалуйсто без оскорблений, можешь помочь помоги, а нет то и не п***и

$ grep -r socket_create linux-2.6.20.2
linux-2.6.20.2/security/selinux/hooks.c:static int selinux_socket_create(int family, int type,
linux-2.6.20.2/security/selinux/hooks.c:        .socket_create =                selinux_socket_create,
linux-2.6.20.2/security/dummy.c:static int dummy_socket_create (int family, int type,
linux-2.6.20.2/security/dummy.c:        set_to_dummy_if_null(ops, socket_create);
linux-2.6.20.2/include/linux/security.h: * @socket_create:
linux-2.6.20.2/include/linux/security.h:        int (*socket_create) (int family, int type, int protocol, int kern);
linux-2.6.20.2/include/linux/security.h:static inline int security_socket_create (int family, int type,
linux-2.6.20.2/include/linux/security.h:        return security_ops->socket_create(family, type, protocol, kern);
linux-2.6.20.2/include/linux/security.h:static inline int security_socket_create (int family, int type,
linux-2.6.20.2/net/socket.c:    err = security_socket_create(family, type, protocol, 1);
linux-2.6.20.2/net/socket.c:    err = security_socket_create(family, type, protocol, kern);

ммм... а это что вообще за socket_create() такой :-?

// wbr

сори ошибочка )) sock_create() в net/sock.h находится

> сори ошибочка )) sock_create() в net/sock.h находится

ну тогда уж sock_create_kern() в том же linux/net.h:

extern int       sock_wake_async(struct socket *sk, int how, int band);
extern int       sock_create(int family, int type, int proto,
                 struct socket **res);
extern int       sock_create_kern(int family, int type, int proto,
                      struct socket **res);
extern int       sock_create_lite(int family, int type, int proto,
                      struct socket **res);
extern void      sock_release(struct socket *sock);
extern int           sock_sendmsg(struct socket *sock, struct msghdr *msg,
                  size_t len);
extern int       sock_recvmsg(struct socket *sock, struct msghdr *msg,
                  size_t size, int flags);

и какой-нить sock_sendmsg() примеры использования которого то-же можно
найти в ядре.

// wbr

> б-же, прибейте их кто-нибудь. Зачем?!!

еще одно быдло считает, что оно умнее всех (я о тебе, анонимный юзер).

>> б-же, прибейте их кто-нибудь. Зачем?!!

>давйте пожалуйсто без оскорблений,

Трудно удержаться, правда.

> можешь помочь помоги, а нет то и не п***и

Твой вопрос вызывает сильные подозрения. Не все хотят помогать в размножении говнокода.

Почитай о средствах, специально предназначенных для общения модулей с userspace - на lwn.net куча информации. Ну там netlink, да хоть ddlink.

> еще одно быдло считает, что оно умнее всех

Приведи пример задачи, для которой отсылка UDP-пакетов из kernel mode является хорошим (ну, хотя бы приемлемым) решением, о мудрейший из регистрантов.

> еще одно быдло считает, что оно умнее всех (я о тебе, анонимный юзер).

> Приведи пример задачи, для которой отсылка UDP-пакетов из kernel mode является хорошим (ну, хотя бы приемлемым) решением, о мудрейший из регистрантов.

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

допусти nfs или что то подобное как обменивается данными с сервером, если есть какоето хитрое решение, то лучше поставте на путь истеный чем, оскорблять или острить

Проблему я решил и пишу этот пост специально для злых языков.

Реализацию работы с сокетами можно подсмотреть в системных вызовах sys_socket, sys_connect, sys_sendto и тд(в файле net/socket.c), а также на ksocket.sourceforge.net есть модуль, в котором функции для работы с сокетами похожи на userspace функции

> а как вызвать метод sentto? в socket->ops его нету

1. смотри в сторону ops->sendmsg
2. не стОит этого делать
есть другие способы достичь нужной функциональности (к примеру /proc)

или задача состоит в обеспечении сетевого взаимодействия с ядром? (что-то наподобие удаленной отладки)

> Приведи пример задачи, для которой отсылка UDP-пакетов из kernel mode является хорошим (ну, хотя бы приемлемым) решением, о мудрейший из регистрантов.


3

.
.
.

2

.
.
.

1

.
.
.

Привожу: Мне например приходилось, в качестве борбы с переполнением буффера сообщений, для того, что-бы debug-жные log-messages из ядра не прое**ались, реализовывать логи по UDP на соседнюю машину, прямиком из ядра. Правда дело было на OS X, там размер буфера сообщений у ядра никак не настраивается, но дело не в этом, а в том, что так категорично, как вы, судить может только быдло, не имеющее реального опыта. Люди с опытом знают, что может быть дофигищи случаев, о которых они могут даже не догадыватся. Ну, на ум еще приходит например iSCSI какой-нибудь, -- очень хороший пример, я правда не помню, поверх UDP или TCP оно делается, не суть важно: приходится в ядре сериализовать SCSI команды в сетевой поток данных, а вынос сетевой части в userspace приведет к проседанию производительности на порядок-другой, и будет сетевой массив читаться не со скоростью 250 Mb/s, обладая при этом отличной латентностью, а дико тормозить на уровне 30 MB/s, еле поспевая обрабатывать запросы.

Бумажку подать, туалетную?

>... и будет сетевой массив читаться не со скоростью 250 Mb/s ...

Предвидя крики злопыхателей: Fiber Channel

> 250 Mb/s, обладая при этом отличной латентностью, а дико тормозить на > уровне 30 MB/s, еле поспевая обрабатывать запросы. 

время перехода между уровнями привилегий несоизмеримо мало по сравнению с пропускной способностью сети
поэтому снижение производительности в 8+ раз мне кажется маловероятным
откуда данные?

> откуда данные?

С потолка :) Однако подкреплены подсознательным опытом. Вспомните дискуссию Торвальдса с Таненбауманом (или как он там), про реализацию FS драйвера. Тут та-же картина, 1-в-1: реализация в userspace сможет обрабатывать запросы последовательно, одно или N поточно, где N=const, в то-же время ядреная реализация будет flexible и fast в этом отношении. Это очень сильно может сказатся на итоговой производительности. Ну и бонально, по поводу количества ctx switch-ей: их количество будет разнится на порядки, между ядреной версией и userspace-ной, т.к. каждый send/recv отдельной iSCSI команды, из userspace приложения, будет ctx switch пораждать. А слишком большими блоками по iSCSI тоже не погоняешь данные.

P.S. чуток загуглив, получил примерное время переключения контекста на x86 linux-е в 2GHz порядка 40 usec (это грубая оценка, по данным отсюда: http://lkml.org/lkml/2004/8/21/77). Какая бы она не была грубая, за время в 40 usec, по 10Gbit Fiber Channel-у можно прокачать 53687 байт, -- не так и мало, сравнимо со средним размером read/write пакета.

Родной, ты путаешь переключение контекста с переключением режима. И даже переключение контекста - отнюдь не 40мкс.

P.P.S. С оценкой я похоже прогнал, времени ctx switch-а, однако первая предпосылка остается в силе, и будет оказывать очень большое влияние на производительность.

> P.P.S. С оценкой я похоже прогнал, времени ctx switch-а, однако первая предпосылка остается в силе, и будет оказывать очень большое влияние на производительность.

Кстати, у кого руки чешутся, проверить это на эксперементе: возьмите TrueCrypt под Linux, версий 4.3 и 5.0, и погоняйте тестами различными, нагрузочными, для сравнения, что и наскольно различается по скорости.

Для справки: у TrueCrypt 4.3 крипто-драйвер был сделан модулем ядра, но в 5-ой версии ребята решили, что свои нервы дороже, и переделали все на FUSE. Т.е. да, получаем примерно один и тот-же код, но в 2х версиях: чистый kernelspace и с выносом логики в userspace.

Если кому будет не лень проверить, закиньте потом результаты на q_md <at> mail <dot> ru , ну или хотя-бы линк на результаты ;)

> Какая бы она не была грубая, за время в 40 usec, по 10Gbit Fiber 
> Channel-у можно прокачать 53687 байт, -- не так и мало, сравнимо со 
> средним размером read/write пакета.

не стОит забывать об _узком_ месте, которым в данном случае является сетевая подсистема ядра
обработка пакетов сетевой подсистемой снизит общую пропускную способность NIC
ksoftirqd выполняется с минимальным приоритетом и постоянно вытесняется более приоритетными процессами, поэтому обработчик отложенного прерывания NET_RX_SOFTIRQ вряд ли "догонит" по скорости NIC

> не стОит забывать об _узком_ месте, которым в данном случае является сетевая подсистема ядра

Вот именно. Вынос "общалки" в userspace, еще более сузит это узкое место. И если я вас правильно понял, то Linux ядро в принципе неспособно эффективно использовать 10 Gbit-ный линк?

> И если я вас правильно понял, то Linux ядро в принципе неспособно 
> эффективно использовать 10 Gbit-ный линк?

скажем так, все зависит от общей загрузки системы (количество процессов, степень их интерактивности и т. д)

не стоит забывать, что стандартное ядро Linux - это все-таки ядро общего назначения, т. е _все_ его характеристики оптимально сбаллансированы для работы в разных средах
не стОит ожидать, что высокоскоростной NIC будет использован на всю катушку

> не стоит забывать, что стандартное ядро Linux - это все-таки ядро общего назначения, т. е _все_ его характеристики оптимально сбаллансированы для работы в разных средах не стОит ожидать, что высокоскоростной NIC будет использован на всю катушку

Не стоит забывать, что если к машине подключают сверхбыстрый SAN по 10Gbit-ному линку, то наверняка ядро там будет далеко не ванильное, а с кучей патчей/оптимизирующих настроек, так что всему что нужно, подкрутят приоритет, везде где нужно, значения подкрутят, так что на то, что сетевая подсистема тормозить будет, не надо жаловатся. К тому-же, на таких быстрых NIC-ах, обычно MTU просто огромный, так что особого потока IRQ не будет, -- не знаю точно как с 10Gbit, но га 1G линках MTU обычно в 64k ставят, т.е. это порядка 2048 прерываний от сетевухи в секунду, при входящем 1Gbit потоке данных, -- современному процу с таким вполне справится можно. А такие "мелочи" как подсчет чексумм, и прочая "оформиловка", нормальными сетевухами делается уже давно аппаратно, так что на это проц не будет отвлекатся. Единственное что ему останется -- организовывать TCP поток данных, да передавать данных между их потребителем и сетью.

Но даже если и оставить ванильное ядро, не верю, что Linux сможет так сильно просадить сетевую производительность, что не сможет на уровне 50 Mb/s входящий поток держать. А при таком потоке, вариант с демоном в userspace-е будет куда больше грузить CPU.

> так что всему что нужно, подкрутят приоритет, везде где нужно, 
> значения подкрутят, так что на то, что сетевая подсистема тормозить 
> будет, не надо жаловатся

никто ничего не подкрутит
чем больше общая загрузка системы, тем менее производительной будет сетевая подсистема
это связано с минимальным приоритетом ksoftirqd

> К тому-же, на таких быстрых NIC-ах, обычно MTU просто огромный, так 
> что особого потока IRQ не будет

значение MTU по большому счету с количеством прерываний не связано: любой уважающий себя NIC не генерирует прерывание для обработки каждого входящего пакета
хотя согласен, при увеличении MTU, общая производительность, конечно, повысится

> А при таком потоке, вариант с демоном в userspace-е будет куда 
> больше грузить CPU

можно проверить на пакетных сокетах

> чем больше общая загрузка системы, тем менее производительной будет сетевая подсистема это связано с минимальным приоритетом ksoftirqd

Если и будет так - ну, поднимут приоритет, делов-то.

> но га 1G линках MTU обычно в 64k ставят, т.е. это порядка 2048 
> прерываний от сетевухи в секунду

что-то не понял, как ты это посчитал?
даже если NIC генерирует прерывание на каждый пакет, то
в среднем размер данных пакета не может быть 32 байта
минимальный IP заголовок = 20 байт, TCP заголовок = 16 байт
уже 36, и это без данных TCP вообще (что крайне маловероятно)

> Если и будет так - ну, поднимут приоритет, делов-то.

nice задается статически (значение 19)
http://www.linux-m32r.org/lxr/http/source/kernel/softirq.c#L488
общий приоритет может посиситься или понизиться исходя из общей интерактивности процесса
при большой нагрузке на сетевую подсистему интерактивность будет падать
следовательно общий приоритет скорее уменшится нежели увеличится
остается еще SCHED_RR, но я не нашел, где идет возможная установка данной стратегии планирования для ksoftirqd

>> Если и будет так - ну, поднимут приоритет, делов-то.

> nice задается статически (значение 19)

ыыыы... :'(

> остается еще SCHED_RR, но я не нашел, где идет возможная установка данной стратегии планирования для ksoftirqd

man chrt

.oO( и эти люди еще рассуждают он настройке систем и производительности сетевого стека )

посыпаю голову пеплом 
ступил
забыл, что все можно сделать вручную из 3-го кольца :)

но тут возникает другой вопрос
а именно, поднимаем приоритет у ksoftirqd - получаем большие тормоза, т. к при большой нагрузке на сетевую подсистему ksoftirqd будет выполняться если не всегда, то очень часто
с другими процессами что делать?

> но тут возникает другой вопрос

Это вопросы о сферическом коне

> при большой нагрузке на сетевую подсистему ksoftirqd будет выполняться если не всегда, то очень часто с другими процессами что делать?

Если это выделенный iSCSI-сервер, то и черт с ними. Или, если железо не тянет нагрузку, нужно менять железо. Или вылизывать драйверы. Или еще что-нибудь делать.

> Если это выделенный iSCSI-сервер, то и черт с ними. Или, если железо 
> не тянет нагрузку, нужно менять железо. Или вылизывать драйверы. Или 
> еще что-нибудь делать.

что я и сказал вначале: нужен тюнинг
стандартная система не будет использовать высокоскоростной NIC в полную силу

>что я и сказал вначале: нужен тюнинг

"Не стоит забывать, что если к машине подключают сверхбыстрый SAN по 10Gbit-ному линку, то наверняка ядро там будет далеко не ванильное, а с кучей патчей/оптимизирующих настроек, так что всему что нужно, подкрутят приоритет, везде где нужно, значения подкрутят" (c) fmj

;)

ok