>>
Чтобы уяснить это, давайте посмотрим, как в реальности пакеты проходят через хост. Принимаемые из сети данные сначала накапливаются в небольшом  внутреннем буфере сетевого адаптера. Когда он заполняется, сетевая карта генерирует прерывание, заставляющее её драйвер скопировать пакет(ы) в сетевой буфер ядра (т.н. mbufs). Пакеты передаются стеку TCP/IP в том виде, в каком они находятся в mbufs. Когда пакет попадает в буфер ядра, большинство операций, производимых с ним, не зависят от его размера, т.к. для них имеет значение только заголовки, а не некоторая общая нагрузка. Это также верно и для пакетного фильтра,  через который проходит пакет в единицу времени, и который принимает решение, заблокировать либо пропустить данный пакет. Если пакет следует перенаправить (forwarding), стек TCP/IP передаст его сетевой карте, которая, в свою очередь извлечет пакет из mbufs и передаст обратно в линию связи.
<<

не всегда так,
во freebsd есть режим polling, когда сетева карта опрашивается ядром 1000 раз в сек (эту величину можно менять), это намного снижает нагрузку на сететевую карту при работе в гигабитной сети

Замечательная статья.
автору и переводчику большое спасибо за труды

1)не на nic, а на процессор.
2)openbsd нет device polling. Максимум что есть в openbsd - irq moderation(mitigation), что описано как возможность отдавать за одно прерывание несколько фреймов.
3)п.2 ограничивает область применения openbsd слабонагруженными роутерами.
4)device polling увеличивает латентность.
5)в linux и solaris поллинг адаптивный - при низких fps nic работает в режиме irq, при высоких - polling.

неплохо в том плане, что быстро и без воды
можно, кое-где подискутировать и добавить парочку замечаний, но в целом - афтару респект и красную  *  книжку
побольше таких статей. а то 90% - какой-то навоз для(или от?) людей, слабо разбирающихся в ИТ

Нечеловечно то, что при помощи pf+altq не сделать ограничение трафика per host. Существует вариант создать на каждый хост отдельную очередь, но так же есть ограничение не более 256. А если хостов больше 500? Более того, такое количество очередей не очень сказывается на производительности роутера.

Это просто вольный перевод статьи про оптимизацию pf. На сколько я знаю в оригинале было три части.... Тут, честно признаюсь, доконца не дочитал. Лень повторно читать

акстись красноглазый

ибо здесь не дятлы http://www.openbsd.org/users.html

"....больше всего меня удивил поряок просмотра записей: почему, правила просматриваются до последнего совпадения, а не до первого как в линухе - ведь так быстрее!?"
есть заветное pass (block) quick on ... но пользоваться нужно аккуратно.

1. мне например бесит ковыряться в командной строке PIX хотя router'ы в этом плане у cisco привосходные, + цена вопроса. В pix самое замечательное это failover но с приходом carp & ifstated ситуация в корне меняется
2. мнооого вариантов существует

хых, в acl established ставить действительно косяк ... Почитайте про флаги TCP.