ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Vadim Goncharov                      2:5020/400     03 Sep 2006  18:40:20
 To : Eugene Grosbein
 Subject : Re: ng_ipacct
 -------------------------------------------------------------------------------- 
 

 Hi Eugene Grosbein! 
 
 On Sun, 03 Sep 2006 13:15:02 +0400; Eugene Grosbein wrote about 'Re: ng_ipacct':
 
  EG>>> Пришла мысль трафик направлять в ng_ipacct не напрямую после ng_tee,
  EG>>> а пропустив через ng_bpf и отфильтровав пакеты его средствами.
  EG>>> Убивается сразу два зайца - снимается лишняя нагрузка с ng_ipacct
  VG>> И добавляется большая нагрузка на ng_bpf. Скорее всего ты все таки
  VG>> проиграешь в производительности.
  EG> В производительности по сравнению с ng_ipacct без ng_bpf
  EG> или по сравнению с ipacctd?
 
 Думаю, что оба варианта, хотя проверять надо.
 
  VG>> Ибо ng_bpf очень прожорлив. Он мало
  VG>> того что делает malloc(9) для каждого пакета, собирая его из цепочки
  VG>> mbuf'ов (потому что bpf требует непрерывноо блока),
  EG> Только если пакет занимает более одного mbuf-а.
  EG> А от чего зависит, будет ли пришедший из vlan'а пакет
  EG> занимать более одного mbuf?
 
 От размера пакета, например. Размер данных mbuf'а - менее 256 байт, а
 mbuf cluster'а - 2 килобайта (для 5.5 на 386). Кроме того, идея mbuf'ов
 - в легком добавлении или удалении заголовков протоколов, так что цепочка
 может запросто получиться и для маленького пакета. Я не вдавался
 в детали работы всех подсистем, так что не знаю, как часто mbuf'ы на
 входе выстраиваются в цепочку, но на выходе из машины это должно
 случаться часто (т.е. вешать ng_bpf лучше всего непосредственно после
 получения входящих с ng_ether, а не после ip_input(), файрвола и т.п.).
 
  VG>> так еще и исполняет
  VG>> инструкции на виртуальной bpf-машине (в 7-ке включили bpf_jitter,
  VG>> компилиирующий в нативный код, но неизвестна производительность
  VG>> сравнительно с ipfw). Кроме того, ассемблер bpf не вполне полноценен
  VG>> - запрещены джампы назад, в результате что-то серьезное в лимит в 512
  VG>> инструкций может и не получиться впихнуть.
  EG> Мне не нужно серьезное. Мне нужно 'not from x.x.x.x/x' и все.
  EG> Получается совсем немножко. А виртуальная машина сильно тормозная?
 
 Hе замерял. Судя по работе tcpdump'а, не очень :) Сравнительно
 с нативными вариантами, конечно, кода в несколько раз больше, но это
 относительный показатель. Для одного 'not from x.x.x.x/x' наверное будет
 нормально.
 
  EG>>> и обходится проблема ipfw tee, который хотя и передает пакет
  EG>>> через ksocket в netgraph, но и прекращает просмотр правил для
  EG>>> этого пакета, а это тут не годится.
  VG>> Уходи с 4-ки - пора уже (at least на таких задачах). А в 6-ке есть
  VG>> нормальный netgraph/ngtee в ipfw. Если совсем уж никак - ipfw divert
  VG>> + ksocket + ng_echo.
  EG> Помнится, во времена 6-CURRENT ipfw divert+ksocket был глючный
  EG> и Глеб эту связку фиксил и делал MFC в пятерку. Информации о том,
  EG> что в для четверки фиксы были нужны/прокоммичены у меня нет.
  EG> Оно нормально работает на четверке?
 
 Рекомендую таки уходить с 4-ки. Её поддержка прекратится уже через
 несколько месяцев.
 
 -- 
 WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
 [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
 --- slrn/0.9.8.1 on FreeBSD 4.11/i386
  * Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор