Анатомия сетевого стека в Linux

>линакс

К логопеду, быдло!

>линакс

К логопеду, быдло!

Товарищи LORовцы, УМОЛЯЮ, не посылайте больше ко мне друг друга!!!!!

ПОЙМИТЕ, Я НЕ МОГУ ВАМ ПОМОЧЬ!!!!!

Я занимаюсь исправлением дефектов РЕЧИ.

Исправлением письма занимаются: хирург (71 кабинет) и орфопатолог (69 кабинет).

Хирург вставляет руки в плечи, если у кого они не из того места растут.

Орфопатолог занимается патологиями правописания. С помощью плётки и наручников заставляет заново проходить краткий курс русского языка для нерусских школ. К крайнем случае назначает эвтаназию.

P.S. Товарищи, обращайтесь к профильным специалистам! Они вам обязательно помогут!

P.P.S. Оставьте меня в покое, пожалуйста! Я уже перешёл на фенобарбитал. :( —————————————————————————————— Исаак Моисеевич Роземброт, логопед со стажем

>> А VxWorks, по рассказам - дерьмо еще то ;)

>То есть там ты не участвовал и авторитетно сорвать покровы не можешь? ;)

VxWorks я не писал, естественно, но от недостатка опыта его использования совсем не страдаю :-) главный его минус - цена :-/

> Кстати, rто такой Рабинович и что он рассказывает? :)

http://www.google.ru/search?q=%D0%A8%D0%B0%D0%BB%D1%8F%D0%BF%D0%B8%D0%BD+%D0%...

> VxWorks я не писал, естественно

О чем и речь... "хорошо там, где нас нет" 8)

>> VxWorks я не писал, естественно

>О чем и речь... "хорошо там, где нас нет" 8)

гм, попробуем зайти с другой стороны...

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

Есть книжка немецких авторов на эту тему. ИМХО, неплохая.

Linux: сетевая архитектура. Структура и реализация сетевых протоколов в ядре The Linux Networking Architecture: Design and Implementation of Network Protocols in the Linux Kernel

Клаус Вейрле

ггггггг

отжогъ :-D

Уважаемый Исаак Моисеевич, я конечно понимаю, что вопрос не к логопеду, но тем не менее, не подскажете голубчик в каком кабинете можно увеличить размер пениса (в диаметре)?

Санчо, специально для тебя изменим размер рабочего органа в радиусе.

>Для embedded sk_buff вообще не годится - из-за отсутствия поддержки фрагментации требует больших буферов, иначе производительность падает катастрофически, кроме этого нет buffer sharing, да и обязательное копирование данных хотя бы раз тоже не конфета для слабых процессоров без DMA каналов

Это уж совсем сказки - фрагментация через страницы в fraglist в sk_buff всегда была. buffer sharing - это что? skb_get()/skb_clone() решают.

Какое копирование, о чем вы?

Это очень феерическое описание того, чего в стеке нет вообще, вы не разобрались.

> Это уж совсем сказки - фрагментация через страницы в fraglist в sk_buff всегда была.

имеется в виду фрагментация пакета

> buffer sharing - это что? skb_get()/skb_clone() решают.

но только в случае read-only доступа

> Какое копирование, о чем вы?

удивляюсь что для вас это новость :-)

> Это очень феерическое описание того, чего в стеке нет вообще, вы не разобрались.

я спорить особо не буду, вот первая более-менее подробная ссылка от гугля: http://www.freelists.org/archives/openbeosnetteam/06-2006/msg00065.html

>> Это уж совсем сказки - фрагментация через страницы в fraglist в sk_buff всегда была.

>имеется в виду фрагментация пакета

Что "фрагментация пакета"? Кусок пакета может быть в skb->data, кусов в списке фрагментов. Не обязательно создавать огромный буфер, чтобы целиком класть туда пакет.

>> buffer sharing - это что? skb_get()/skb_clone() решают.

>но только в случае read-only доступа

Неверно.

>> Какое копирование, о чем вы?

>удивляюсь что для вас это новость :-)

Понятно, ответить не можете.

>> Это очень феерическое описание того, чего в стеке нет вообще, вы не разобрались.

>я спорить особо не буду, вот первая более-менее подробная ссылка от гугля: http://www.freelists.org/archives/openbeosnetteam/06-2006/msg00065.html

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

3) sk_buff/Linux: variable sized allocations, single buffer per packet, leaves space in the beginning for additional headers, and space at the end for additional data. Also has a separate structure for the header. pro: * linear buffer

Да, skb->data есть линейный буфер.

* no fragmentation of data

Неверное, смотреть в сторону fraglist

* clean API * very cheap prepending/appending *if* there is enough space left

Так и есть.

* must always copy data at least once

Где копировать-то? Из userspace через socket API, так на то оно и socket API. zerocopy есть через splice (vmsplice и т.д.) и sendfile (теперь реализовано через splice).

con: * needs a more complex allocator

BeOS не осилил SLAB? В сетевом стеке используется стандартный аллокатор Linux.

* splitting the buffer is expensive (fragmenting existing packets)

Бред. Выделяется страница и кладется в fraglist, все.

* appending/prepending can get very expensive, too (if the original reserved space was not enough) - this might be lifted by intelligent stack design (which would then potentially wastes more memory)

Во-перых, это было сделано специально для повышения скорости. Во-вторых, добавлять данные можно через fraglist. В-третьих, не нужно сюда тащить медленнейшие mbuf'овские привычки - специально есть skb->head/data/tail/end указатели для наибольшей скорости. Да, у этого подхода есть ограничения (при максимально скорости из всех возможных), но тогда скажите, зачем openbsd пошла тем же путем, и теперь выделяет бОльший mbuf и делает такой же набор смещений как в skb?

* does not allow to share data buffers (only allows for read-only clones)

Ну неверно же - делаете клона (skb_clone()) и хоть обпишитесь в общие данные. Другое дело, что реализация протоколов это может не позволить (как например вы себе представляете запись в ip заголовок каких-то значение, пока они могут использоваться другими пользователями?), но в качестве примера возьмите hardware checksum offloading - железка/драйвер может писать в пакет tcp/ip контрольные сумы параллельно со стеком, который теоретически может менять данные тоже (хотя смысла в этом и нет).

ну вот опять! ну нельзя разговаривать в терминах "ниасилил" и т.п., это шапкозакидательство только для флеймеров интересно. Проблемы есть и всем они известны. По поводу фрагментации - еще раз, не фрагментация данных пакета, а именно сложный пакет, что позволяет mbuf но не позволяет sk_buff, zero copy - может и появился костыль, я не в курсе последних веяний, но идеология sk_buff изначально его не предполагала (что и требовалось доказать - линакс стек это сплошной хак), sharing в линаксе не очень нужен, но это не значит что он не нужен везде, и т.д.

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

"Проблемы есть и всем они известны." это тоже из разряда, не осилил. Аргументов больше и технических деталей.

>ну вот опять! ну нельзя разговаривать в терминах "ниасилил" и т.п., это шапкозакидательство только для флеймеров интересно. Проблемы есть и всем они известны. По поводу фрагментации - еще раз, не фрагментация данных пакета, а именно сложный пакет, что позволяет mbuf но не позволяет sk_buff, zero copy - может и появился костыль, я не в курсе последних веяний, но идеология sk_buff изначально его не предполагала (что и требовалось доказать - линакс стек это сплошной хак), sharing в линаксе не очень нужен, но это не значит что он не нужен везде, и т.д.

Что такое "сложный пакет"? mbuf в bsd в основном используется для прикрепления тегов на каждом уровне, все эти теги в skb живут в skb->cb, и у них есть строго определенный жизненный цикл (там, где bsd создает и удаляет новые объекты, в linux используется skb->cb). Так что же позволяет mbuf, чего не позволяет skb? Хотя бы один пример! И вы так и не рассказали, почему же производительность форвардинга пакетов с включенным PF в openbsd возросла в 2 (!) раза после удаления одной (!) дополнительной аллокации mbuf'a?

zerocopy - вы понятия не имеете, о чем говорите. Наверное слышали о поддержке recv zero copy в freebsd для единственного драйвера путем замапливания пользовательских страниц, но кучу проблем с этим вы забыли упомянуть... sendfile() вот и все, что есть. recvfile есть только в linux (в виде splice). skb всего лишь набор контрольных правил для передачи пакета, он не имеет никакого отношения к "идеологии" и другим маркетинговым словечкам, которыми вы пытаетесь пользоваться.

Да, кстати, вы так и не привели ни одного технического аргумента, но оперируете только такими словами как "идеология", "сплошной хак" и т.п.

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

>линакс

К логопеду, быдло!

Увы, но логопед тут похоже бессилен.. :( Такие запушенные стадии способен вылечить только профессор Луговский..

>>О чем и речь... "хорошо там, где нас нет" 8)

>гм

Вот эту твою фразу: "попса :-) (в MVL лично участвовал)" я понял так - "MVL - это дешевая поделка, хотя и популярная, но не отличающаяся качеством - я могу судить об этом как человек, знающий его разработку изнутри". Ты это хотел сказать или нет? После этого ты одобрительно отзываешься о качестве VxWorks, хотя и не участвовал в ее разработке. Поэтому я и вспомнил пословицу "хорошо там, где нас нет".

> http://www.google.ru/search?q=%D0%A8%D0%B0%D0%BB%D1%8F%D0%BF%D0%B8%D0%BD+%D0%.

Блин, да знаю я анек про Рабиновича и Шаляпина, там же стоял смайлик. Я к тому, что ты не знаешь, кто мне рассказывал о VxWorks, не знаешь их квалификации - так что не тебе сравнивать их с кем угодно.