Что вы этим хотите сказать?
Если у вас есть замечания по существу, высказывайтесь развёрнуто здесь или в личном сообщении мне.
Если вы преследуете какие-то другие цели, то нам с вами не по пути.
Вы отлично всё написали. У меня всё было ещё грустнее, чем у Вас: 90-е, отдалённый регион, не самое лучшее филологическое образования, аспирантура (не та, куда хотел), преподавание (не то, о котором изначально мечтал). В 30 ушёл из вуза в никуда. Работал переводчиком, потом стал работать техническим писателем. Изучаю C и Python. Скоро меняю работу на более интересную.
Вообще от поллинга отказались, ибо проц в холостую пашет, но зато задержки типа меньше.
Если честно, не понял, что вы имеете в виду. Попробуйте, пожалуйста, сформулировать эту мысль другими словами.
DPDK вроде как прибит на гвозди к интелу.
Да, DPDK был создан Intel для собственных сетевых карт. Драйверы для других карт (<a href=«http://dpdk.org/doc/guides/nics/mlx4.html» target="_blank" rel=«nofollow»">Mellanox, Emulex) есть, но с ними далеко не все гладко. Например, во время экспериментов с DPDK мы установили драйвер для Mellanox, но ничего не завелось, хотя всё делали точь-в-точь по инструкции. Зато все получилось сразу, как только мы заменили карту Mellanox на Intel.
netmap работает с кучей железа, там есть какие то минимальные требования к самим сетевухам, типа наличия DMA и колец дескрипторов.
Автор — Луиджи впилил поддержку в дрова реалтека, интела и пр.
Да, netmap гораздо менее «завендорлочен». Ну и тут есть свои подводные камни: например, полноценной поддержки карт Mellanox нет до сих пор (см. здесь).
К сожалению, в течение последних двух дней был вдалеке от компьютера и Интернета, поэтому отвечаю только сейчас.
… вы уж сильно не обижайтесь =)
Обижаться и никто и не собирается =) Более того, моя реакция будет совершенно противоположной: я очень рад, что вы внимательно прочитали статью и благодарен вам за конструктивные замечания. Вообще, обижаться на критику, если она конструктивная — это не про меня. Я не боюсь признавать свои ошибки, а тот же Хабр считаю местом не для демонстрации собственной крутизны, а для дискуссий, взаимного обучения и обмена мнениями.
по этому слинковать приложение, используюещее сокет апи с дпдк просто так в лоб не получится (на самом деле на сегодняшний день существует ряд TCP стеков поверх дпдк — rumptcp, mtcp(кстати от автора packetshader))
Прекрасно понимаю и сейчас жалею, что ясно не выразил это в тексте.Спасибо за замечание. Про TCP-стеки поверх DPDK обязательно почитаю поподробнее (кстати, если знаете полезные ссылки по теме, буду очень признателен).
На самом деле кольцевая структура — rx ring — это кольцо дескрипторов. В этой структуре не содержатся сами пакеты (они сперва попадают в fifo буфер NIC), там содержатся указатели на область памяти, куда делать DMA + ряд других полей, куда NIC пишет после успешного DMA (write back), например длина пакета, оффлоадинг флаги итд.
Это я знаю; в тексте выразился не совсем удачно. Все указанные вами сомнительные и неудачные фразы я либо отредактировал, либо вообще убрал.
… то, что вы называете головой и хвостом в rte_ring.h называется prod.head и cons.head
Это я знаю. Там ещё prod.tail и cons.tail есть. И здесь мы уже из обсуждения чисто технических деталей смещаемся в плоскость терминологии и стилистики. Конечно, в тексте можно писать как в rte_ring.h — но это делает его более тяжеловесным и нечитабельным. Я не пурист, не против заимствования терминов из других языков (если в нашем языке таковых нет), но ералаша из русских и латинских букв в тексте не люблю. К тому же термины «голова» и «хвост» применительно к кольцевому буферу в русском языке можно считать общеупотребительными.
Ничего не понятно что вы имели ввиду. С одной стороны — да, rte_mbuf сильно меньше sk_buff, но его нельзя сравнивать с так же разросшимся mbuf во FreeBSD.
Насколько я понимаю, истоки идеи, лежащей в основе rte_mbuf, восходят к FreeBSD. Если в Linux для всех типов пакетов используется структура sk_buff (о недостатках такого подхода мы уже говорили выше), то в FreeBSD используются mbuf, которая гораздо меньше по размеру и которые для обработки больших пакетов могут объединяться друг с другом (как buffer chaining в DPDK). Когда я прочитал про rte_mbuf, мне это сразу напомнило «фряху».
Вот для примера Брюс Ричардсон несколько часов назад читал доклад, в котором показал один из кейсов поиска узкого места.
За ссылку на доклад огромное спасибо!
В заключение хочу ещё раз поблагодарить вас за все высказанные замечания, эта как раз так критика, которая помогает нам стать лучше =). Именно ваш комментарий оказался самым ценным из всех.
При работе над следующей статьёй многие ваши замечания я буду держать в уме.
И хотел бы спросить: а где вы так хорошо изучили DPDK? используете ли вы DPDK для решения каких-то практических задач? Заранее благодарю и надеюсь на продолжение диалога.
Я эту картинку прекрасно знаю. Более того, мы в одной из предыдущих публикаций её уже использовали.
Если говорит о Sysdig, то он собирает информацию абсолютно обо всём и с его помощью можно сделать то, для чего в других условиях потребовалось бы несколько инструментов. Он сразу показывает то, что с помощью других инструментов нужно ещё «нарыть».
А ещё он отличается гибкостью и низким порогом вхождения (синтаксис тех же правил и фильтров очень прост).
Что касается Falco, то он умеет гораздо больше, чем другие инструменты для аудита безопасности, а ещё даёт гораздо более подробную и человекопонятную информацию.
>>>>А у OpenStack Swift API примерно 10 июня этого года вы изменили имя контейнера с Common на common (да-да, они регистрозависимые), остановив работу трех моих приложений.>>>>
Из такой формулировки неясно, что имеется в виду. Поясните, пожалуйста. И если такая проблема была, лучше пишите о ней не здесь, а создайте тикет с как можно более подробным описанием.
Любой инструмент должен использоваться сугубо по назначению. JSON был создан для обмена данными в вебе, а не для описания API — об этом здесь в комментариях уже писали. Поэтому при составлении документации к API поневоле приходится прибегать к помощи «костылей». Да и составлять в JSON длинные описания довольно утомительно… И не менее утомительно их читать (на это уже обратил внимание другой комментатор).
Насчёт Мессиана Вы правы, очень не хватает. И в свете прочитанной статьи было бы интересно взглянуть на его трактат о ритме другими глазами.
А ещё интереснее было бы развить тему на обширном материале авангардной музыки ХХ века, которая во многом инспирирована опытом неевропейских культур и традиций.
Такие кейсы мы рассмотрим и постараемся обо всём этом написать, но уже в новом году.
Если у вас есть замечания по существу, высказывайтесь развёрнуто здесь или в личном сообщении мне.
Если вы преследуете какие-то другие цели, то нам с вами не по пути.
https://habrahabr.ru/company/selectel/blog/308208/
https://habrahabr.ru/company/selectel/blog/303190/
https://habrahabr.ru/company/selectel/blog/271957/
Если честно, не понял, что вы имеете в виду. Попробуйте, пожалуйста, сформулировать эту мысль другими словами.
Да, DPDK был создан Intel для собственных сетевых карт. Драйверы для других карт (<a href=«http://dpdk.org/doc/guides/nics/mlx4.html» target="_blank" rel=«nofollow»">Mellanox, Emulex) есть, но с ними далеко не все гладко. Например, во время экспериментов с DPDK мы установили драйвер для Mellanox, но ничего не завелось, хотя всё делали точь-в-точь по инструкции. Зато все получилось сразу, как только мы заменили карту Mellanox на Intel.
Да, netmap гораздо менее «завендорлочен». Ну и тут есть свои подводные камни: например, полноценной поддержки карт Mellanox нет до сих пор (см. здесь).
Обижаться и никто и не собирается =) Более того, моя реакция будет совершенно противоположной: я очень рад, что вы внимательно прочитали статью и благодарен вам за конструктивные замечания. Вообще, обижаться на критику, если она конструктивная — это не про меня. Я не боюсь признавать свои ошибки, а тот же Хабр считаю местом не для демонстрации собственной крутизны, а для дискуссий, взаимного обучения и обмена мнениями.
Прекрасно понимаю и сейчас жалею, что ясно не выразил это в тексте.Спасибо за замечание. Про TCP-стеки поверх DPDK обязательно почитаю поподробнее (кстати, если знаете полезные ссылки по теме, буду очень признателен).
Это я знаю; в тексте выразился не совсем удачно. Все указанные вами сомнительные и неудачные фразы я либо отредактировал, либо вообще убрал.
Это я знаю. Там ещё prod.tail и cons.tail есть. И здесь мы уже из обсуждения чисто технических деталей смещаемся в плоскость терминологии и стилистики. Конечно, в тексте можно писать как в rte_ring.h — но это делает его более тяжеловесным и нечитабельным. Я не пурист, не против заимствования терминов из других языков (если в нашем языке таковых нет), но ералаша из русских и латинских букв в тексте не люблю. К тому же термины «голова» и «хвост» применительно к кольцевому буферу в русском языке можно считать общеупотребительными.
Насколько я понимаю, истоки идеи, лежащей в основе rte_mbuf, восходят к FreeBSD. Если в Linux для всех типов пакетов используется структура sk_buff (о недостатках такого подхода мы уже говорили выше), то в FreeBSD используются mbuf, которая гораздо меньше по размеру и которые для обработки больших пакетов могут объединяться друг с другом (как buffer chaining в DPDK). Когда я прочитал про rte_mbuf, мне это сразу напомнило «фряху».
За ссылку на доклад огромное спасибо!
В заключение хочу ещё раз поблагодарить вас за все высказанные замечания, эта как раз так критика, которая помогает нам стать лучше =). Именно ваш комментарий оказался самым ценным из всех.
При работе над следующей статьёй многие ваши замечания я буду держать в уме.
И хотел бы спросить: а где вы так хорошо изучили DPDK? используете ли вы DPDK для решения каких-то практических задач? Заранее благодарю и надеюсь на продолжение диалога.
Если говорит о Sysdig, то он собирает информацию абсолютно обо всём и с его помощью можно сделать то, для чего в других условиях потребовалось бы несколько инструментов. Он сразу показывает то, что с помощью других инструментов нужно ещё «нарыть».
А ещё он отличается гибкостью и низким порогом вхождения (синтаксис тех же правил и фильтров очень прост).
Что касается Falco, то он умеет гораздо больше, чем другие инструменты для аудита безопасности, а ещё даёт гораздо более подробную и человекопонятную информацию.
Из такой формулировки неясно, что имеется в виду. Поясните, пожалуйста. И если такая проблема была, лучше пишите о ней не здесь, а создайте тикет с как можно более подробным описанием.
https://github.com/gogits/gogs/issues/936
https://github.com/gogits/gogs/issues/776
Будем надеяться, что реализуют, и ждать долго не придётся.
А ещё интереснее было бы развить тему на обширном материале авангардной музыки ХХ века, которая во многом инспирирована опытом неевропейских культур и традиций.