Это, конечно, интересно, но здесь громадная проблема - производительность. Когда там 5-tuple и FSM того же TCP сразу захаркожены на Си - производительность приличная. Как только мы вводим этот уровень абстракции - она сразу падает, возможно весьма значительно.
возможно да. возможно нет. я пока не вижу принципиальных проблем реализации 5-тупле в виде абстракции с той же производительностью (ну почти той же). в конце концов 5-тупле -- это 3 поля фиксированной длинны по фиксированному смещению + 2 поля фиксированной длинны по чуть менее произвольному смещению. 5 операций косвенности условно говоря. скорее всего на общем фоне разницы не будет. с FSM не так очевидно. но почему бы FSM в виде талицы должна быть существнно медленнее FSM на switch?
ну и кроме того, FPGA ты не обгонишь, а скрость кодирования поддержки новых протоколов и расширения -- она не менее важна, а скорее и более. в конце концов более двух десяток в тазик нынче не актуально, а 24 ядра на это хватит (если десток не две, то их скорее всего надо уже двадцать четыре, а столько в тазик не запихаешь да и память и pci-e сдохнет).
Тут вон производительность pf и libalias даже на одном ядре сравнивали - заметно отличается, при том что оба на сях. Потому что куча всякого роляет типа кэшей процессора и др. (там RB-дерево vs хэш).
а у кого что, у кого сколько?
А ведь у людей есть потребность гонять в определенных условиях даже вообще без динамики - на 10 Гбит например. Про тот же иптаблес рапортовали, в нем отключение может резко поднять производительность (а ведь никаких абстракций). Тоже такие потребности учесть надо.
10гбит на одном ядре невозможно и не нужно. отключение чего в iptables? и да, statefull производительность будет просаживать. безусловно. независимо от реализации. это надо понимать и на это надо идти. просто надо либо отключать state либо в таких случая предлагать использовать обычный ipfw, почему нет? как stateless от вполне употребимый, поскольку работает в контексте прерывания драйвера -- по ядрам раскладывается сам. в конце концов от Cat6500 на 10G/40G никто умных acl не ждет -- они там простые, которые в FPGA реализованны.
А ты в tcpdump -d хотя б погляди, на какой-нибудь аналог правила ipfw. Да, некоторые опкоды оттранслируются один в один. Но другие - разъедутся в десятки. Декомпиляция - возможность из опкодов собрать обратно исходник для операции листинга (ipfw show, iptables -L), так, чтобы исходник не хранить - мало ли его кто потёр или изменил или он там нечитаем (случаи разные бывают, по идее в файрвол должно быть можно вкурить по выводу листинга из ядра, на что Корчмарь и ругался, что у ipfw это сложнее).
в листе дерева можно хранить ссылку на строку, из которой этот лист образовался и показывать именно ее. gdb ведь не занимается декомпиляцией до си при пошаговой отладке.
Было б оно совсем кривое, оно б не выжило. Да и у нас проблема выжить, и если это мало кто осилит - значит не годится. К тому же не забывай про правило 80/20 и что оно пока делается в одиночку, и даже мной отнюдь не всё время даже без работы (на халтурках подрабатывать приходится) - если сильно уж навернуть, можно ниасилить.
да, делать надо так, что бы 80% обычных пользователей было понятно, сложности от них были спрятанны, задачи решались бы легко. смысла делать еще одну простую поделку я не вижу. потребности в еще одном обычном стиральном порошке файрволе, но в нетграфе -- нет. файрвол нужен хороший и в котором добавление поддержки еще одного протокола не выливается в месяц работы. если трудоемкость будет высокая, но профит очевидный -- трудовые ресурсы как-то найти будет можно. но это потом.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2012-05-25 06:17 am (UTC)возможно да. возможно нет. я пока не вижу принципиальных проблем реализации 5-тупле в виде абстракции с той же производительностью (ну почти той же). в конце концов 5-тупле -- это 3 поля фиксированной длинны по фиксированному смещению + 2 поля фиксированной длинны по чуть менее произвольному смещению. 5 операций косвенности условно говоря. скорее всего на общем фоне разницы не будет. с FSM не так очевидно. но почему бы FSM в виде талицы должна быть существнно медленнее FSM на switch?
ну и кроме того, FPGA ты не обгонишь, а скрость кодирования поддержки новых протоколов и расширения -- она не менее важна, а скорее и более. в конце концов более двух десяток в тазик нынче не актуально, а 24 ядра на это хватит (если десток не две, то их скорее всего надо уже двадцать четыре, а столько в тазик не запихаешь да и память и pci-e сдохнет).
а у кого что, у кого сколько?
10гбит на одном ядре невозможно и не нужно. отключение чего в iptables?
и да, statefull производительность будет просаживать. безусловно. независимо от реализации. это надо понимать и на это надо идти. просто надо либо отключать state либо в таких случая предлагать использовать обычный ipfw, почему нет? как stateless от вполне употребимый, поскольку работает в контексте прерывания драйвера -- по ядрам раскладывается сам. в конце концов от Cat6500 на 10G/40G никто умных acl не ждет -- они там простые, которые в FPGA реализованны.
в листе дерева можно хранить ссылку на строку, из которой этот лист образовался и показывать именно ее. gdb ведь не занимается декомпиляцией до си при пошаговой отладке.
да, делать надо так, что бы 80% обычных пользователей было понятно, сложности от них были спрятанны, задачи решались бы легко. смысла делать еще одну простую поделку я не вижу. потребности в еще одном обычном
стиральном порошкефайрволе, но в нетграфе -- нет. файрвол нужен хороший и в котором добавление поддержки еще одного протокола не выливается в месяц работы. если трудоемкость будет высокая, но профит очевидный -- трудовые ресурсы как-то найти будет можно. но это потом.