Re: ng_ipacct

From

Vadim Goncharov (2:5020/400)

To

Eugene Grosbein (2:5054/37.63)

Date

2006-09-03T18:40:20Z

Area

RU.UNIX.BSD

From: Vadim Goncharov <vadimnuclight@tpu.ru>

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> Получается совсем немножко. А виртуальная машина сильно тормозная?

Не замерял. Судя по работе 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)
SEEN-BY: 50/12 203 400/814 450/159 186 1024 451/30 461/43 132 640 469/999
SEEN-BY: 550/196 4616/3 4625/8 4635/4 4641/444 5000/76 5000 5006/1 5007/1
SEEN-BY: 5010/70 352 5011/13 5012/46 5015/28 5019/31 5020/18 154 175 194 400
SEEN-BY: 5020/545 549 715 758 982 1057 1523 1604 1630 1909 1922 2142 2238 2395
SEEN-BY: 5020/2450 2590 2871 4441 5021/3 29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/12 5029/32 5030/49 500 556 966 1063 1080 1900 1957 2828 5031/47
SEEN-BY: 5031/70 5034/10 13 5035/3 38 5036/1 5040/47 5042/13 5045/7 5049/1 50
SEEN-BY: 5049/97 5051/15 5054/1 4 8 9 11 28 35 36 37 45 63 66 67 70 75 84 85
SEEN-BY: 5055/95 5057/1 5059/9 5060/88 5061/15 5062/1 10 5063/3 5064/7 5066/18
SEEN-BY: 5074/9 5075/5 5077/70 5080/80 1003 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5094/4 5095/20 5096/18 5099/11 6001/3 10

PATH: 5020/400 4441 545 5054/1 37