make.kernel

network aaa.bbb.204.0/22 network aaa.bbb.204.0/23 network aaa.bbb.206.0/24 network aaa.bbb.207.0/24 neighbor peer_1 { descr "first_peer" } neighbor peer_2 { descr "second_peer" } neighbor peer_3{ descr "third_peer" } deny to any allow to peer_1 prefix aaa.bbb.204.0/22 allow to peer_1 prefix aaa.bbb.204.0/23 allow to peer_2 prefix aaa.bbb.204.0/22 allow to peer_2 prefix aaa.bbb.206.0/24 allow to peer_3 prefix aaa.bbb.204.0/22 allow to peer_3 prefix aaa.bbb.207.0/24 peer_x - ip-адреса пиров. Где-то так, по памяти, давно это было. Использовать морспецифики для балансировки трафика это даже не в ногу, в голову себе стрелять, просите у пиров управляющие комьюнити.

Когда директ включён, то сетевуха генерит прерываание о том что данные получены, и система начинает обрабатывать полученные данные прямо в из обработчика этого прерывания. Когда выключено, то во время прерывания полученные данные ставятся в специальную очередь и на этом работы обработчика прерываний заканчивается. Данные из очереди обрабатывают isr потоки, которых запущено по количеству ядер и они прибиты к ядрам. В 9.х крутилки чуточку поменяли название и net.isr.direct (+форс крутилка) стал только для чтения, а крутится через: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. #net.isr.bindthreads=1 # Bind netisr threads to CPUs net.route.netisr_maxqlen=1024 # maximum routing socket dispatch queue length net.inet.ip.intr_queue_maxlen=4096 # Maximum size of the IP input queue. Should be increased until net.inet.ip.intr_queue_drops is zero Как работает гибрид вариант - я хз. гибрид работает как гибрид, и директом и дефером :) Если поток netisr на том-же ядре что и обработчик прерывания пакет в очередь не ставится и обрабатывается в обработчике прерывания, тоесть получается директ. Если же netisr считает, что пакет будет обрабатываться на другом ядре он ставится в очередь и ждет там пока трид netisr на нужном ядре не освободится, тоесть получается дефер. Теоретически нет смысла ставить пакет в очередь и потом доставать его оттуда только для того, чтобы разбудить поток netisr на том-же ядре, можно протолкнуть пакет прямо в обработчике прерывания. Это то, что я понял из исходников netisr, но там немного магии есть, а у меня скилы такие заклинания не тянут. Кстати где-то проскакивала инфа, что очереди netisr собирались переписать на ringbuff, типа это заметно уменьшит overhead от постановки в очередь/выемки из очереди, но я хз как там процесс.

ИМХО рутер для сети на 500-1000 физиков будет тазик "терминация-нат-шейпер" и в этом случае бздя несколько проще для человека, который ни с ней ни с линуксом не работал. Так, например, водрузив mpd5 получаются что РРТР что РРРоЕ - все единообразно и в ядре с шейпером в виде ng_car, и netflow в виде того-же ng_netflow и радиусом и вебмордой и консольной рулилкой и сбросом абонента по ответу на radius accounting. Ну это не терминация туннелей стого говоря, а куча обвязки, просто удобно подобрана - радиусом ответ сормировал и забыл, в самых простых случаях ложишь атрибуты в базу, даже rlm не нужен. А порулить линуксовым htb как для примера новичку так это маны воскуривать до отвала легких. А пакеты из карточки в карточку с заданой скоростью перекладывать это да, даже винда умеет.

А он точно восьмиядерный или hyperthreading включен?

Это я больше для себя (и Ivan_83) ng_nat и прочее libalias-based прямо из коробки без дополнительных ухищрений организует очередь из желающих - потому что защищается мьютексом, то есть не более одного пользователя одноврменно. Это, кстати, еще одна мораль - не пихайте всех в один нат, а сделайте большую их пачку У меня 16 натов, делал больше - прироста не видно.

Можно, но зачем? Лучше честно перевести netisr на buf_ring, как и большинство сетевых драйверов. Для этого мозгов нужно немного более, чем у меня есть. Теоретически можно прогнать всех, кому не нужен нат через fastforwarding, оно хорошо и быстро, а кому нужен - завернуть в нетграф и организовать очередь там вокруг ng_nat, пусть толкутся. Заодно получится померять нагрузку, создаваемую натом, я так понял она в ng_queue вылезет. Не знаю насколько это повлияет на общую производительность, но попробовать никто не мешает.

ИМХО нат грузит, если отключить его можно валить трафика пока в скорости портов не упрешься, затраты на проверку правил ipfw по сравнению с libalias не имеют значения. А, да, если вы в количество правил упираетесь ipfw add 65534 allow all from any to any in recv \{vlan4000, vlan4001\} 65534 allow ip from any to any in recv {vlan4000,vlan4 позволит экономить еще строчек В мейл-листах проходило что-то поро мэппинг имен интерфейсов в таблицах с использованием radix tree, что-то такое, не пробовал, должно быть феерически круто

Насчет пилили или не пилили - заглянул в код а там новое появилось, может из-за того, что не особо свежая 8 использовалась я и не видел этого. Идея была привязать обработку пакета к ядру процессора с момента получения прерывания, и до постановки в очередь на отправку, ну а вдруг там кеш оптимальнее использоваться будет и наступит щастье. Карточки у меня в машинках и em и igb, igb работают в 1 поток - всеравно PPPoЕ молотят, прерывания от них развешаны cpuset - каждой карточке свое ядро, поэтому брал curcpu как исходные данные для привязки. Железо возле рутера не особо хорошо трафик по портам раскладывает, тоже видать не умеет non-ip, из-за этого не симметрично проц грузится, igb0 может занимать 80% cpu когда igb1 60%, хотя оба они в lagg0, это судя по top. Ну и в случае критической нагрузки показалось полезным быстро выгружать пакеты из карточки и ставить их в очередь netisr которая намного длиннее, при этом растет задержка но ошибок на интерфейсе нет. Опять-же, следующим шагом - не бейте меня сильно - планировалось включить гипертрейдинг на рутере. Типа ядро 0 будет быстренько обрабатывать прерывания и складывать пакеты для netisr в очередь для ядра 1, которое будет грести тяжелую задачу форвардинга с натом (тоже не бейте сильно, но поставить 20 РРРоЕ серверов мне показалось проще и надежнее, чем городить цепочку убертазиков каждый-под-задачу). Конечно-же гипертрейдинг не создает ядра, тут я самовнушением не занимаюсь, но вроде как процессору должно быть легче. Я не знаю досконально как архитектуру процессора так и ядро, могу быть не прав, это просто эксперименты в стиле "а вдруг можно лучше". Кстати, если есть вариант получить у системы идентификатор ядра-компаньйона по гипертрейдингу буду весьма благодарен за информацию куда копать.

Появилось, на днях выложим. И драйвер таки нужен. Другое дело, что разница может быть заметной начиная с 300-400kpps, чего на em бывает редко. Настройками не поделюсь, не рулится оно простыми sysctl. Для нормального распаралеливания нужен нормальный flowid, я его рассчитал примерно вот так: ... case ETHERTYPE_ARP: Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то. http://static.ipfw.ru/patches/netisr_ip_flowid.diff Я скорее всего через какое-то время закоммичу это в базу. Пока проблема в том, что и сам netisr тоже надо переписывать, на buf_ring(9), вместо очередей с мьютексом - с ним производительность проседает процентов на 20 от direct isr Я на 9-stable перевел рутера, там netisr допиливали в плане кучи очередей, нарисовал себе вот такой-вот патчик. Основной смысл - привязать пакет к cpu на котором он первый попал в машинку и дальше обрабатывать его только на этом cpu. Как обычно кривовато, навреное засунувшему грязные руки в mbuf их должно оторвать по самые пятки, но у меня в бою 100 кппс на карточку молотит нормально, аптайм пока месяц. А есть ли какое более элегантное решение сохранить меточку в mbuf? А то я где нашел там и прилепил. isr.diff.txt

Только я в этом мире гружу фрю с флешек с подмонтированием винтов где нужно и куда нужно или еще кто-то? В виртуалке пересобрал мир+ядро+пактыпортапгрейдом, проверил, что все запускается, mdconfig прицепил образ, проинсталил систему потом в chroot проинсталил пакеты, нарисовал конфиги, при первом старте подправил ошибки. Геморойно немного, зато старую флешку потом воткнуть можно, если новая заглючит и парк серверов нада планировать изначально под такую схему.

А он контрольную сумму ethernet-части пересчитает? С первой попытки не заметил опции, для уровней выше есть, может смотрел не туда? conf->csum_flags &= CSUM_IP | CSUM_TCP | CSUM_UDP | CSUM_SCTP;

Стесняюсь спросить, но тут смотрели? http://caia.swin.edu.au/urp/diffuse/ Или это совсем не то?

А я бы гипертрейдинг отключил нафиг, от него только top ядрами обрастает и админ расслабляется. И процессор второй вынул, не нужен он там. 5620 ксеон в качестве рррое-концентратора соло молотит под 200 кппс в каждую сторону с натом шейпером, шахматами и поэтессами. При этом успешно укладываются в планку 4 порта собраные в 2 lagg практически без тюнинга. А много потоков это не всегда хорошо, иногда даже плохо.

А пробовали добавить аналогичный код для Ethernet фреймов (PPPoE)? судя по netisr.h можно и ethernet фреймы так обработать. И можно еще подумать над hash функцией от исходных данных. Не пробовал, просто и так трафик размазался достаточно хорошо.

Настройками не поделюсь, не рулится оно простыми sysctl. Для нормального распаралеливания нужен нормальный flowid, я его рассчитал примерно вот так: diff -Nur /usr/src/sys/net/if_ethersubr.c /root/src/sys/net/if_ethersubr.c --- /usr/src/sys/net/if_ethersubr.c 2010-09-12 01:02:36.000000000 +0300 +++ /root/src/sys/net/if_ethersubr.c 2010-11-11 22:57:29.000000000 +0200 @@ -621,6 +622,11 @@ ifp->if_imcasts++; } + m->m_flags |= M_FLOWID; + m->m_pkthdr.flowid = eh->ether_dhost[0] + eh->ether_dhost[1] + eh->ether_dhost[2] + eh->ether_dhost[3] + eh->ether_dhost[4] + eh->ether_dhost[5]; + m->m_pkthdr.flowid += eh->ether_shost[0] + eh->ether_shost[1] + eh->ether_shost[2] + eh->ether_shost[3] + eh->ether_shost[4] + eh->ether_shost[5]; + + #ifdef MAC /* * Tag the mbuf with an appropriate MAC label before any other @@ -830,6 +836,29 @@ if ((m = ip_fastforward(m)) == NULL) return; isr = NETISR_IP; + + struct ipheader { + u_char offset [12]; //ip header fields not actually needed here + u_char src [4]; //ip src + u_char dst [4]; //ip dst + } __packed __aligned(4); + + if (m->m_pkthdr.len < sizeof(struct ipheader)) { //from ip_fastforward + if_printf(ifp, "flowid math: discard frame with too small header\n"); + goto discard; + } + if (m->m_len < sizeof (struct ipheader) && + (m = m_pullup(m, sizeof (struct ipheader))) == NULL) { //ip_fastforward + if_printf(ifp, "flowid math: discard frame at pullup\n"); + return; /* mbuf already free'd */ + } + struct ipheader *ip; + ip = mtod(m, struct ipheader *); + m->m_pkthdr.flowid += ip->src[0] + ip->src[1] + ip->src[2] + ip->src[3]; + m->m_pkthdr.flowid += ip->dst[0] + ip->dst[1] + ip->dst[2] + ip->dst[3]; + +// if_printf(ifp, "Calculated flow id %d\n", m->m_pkthdr.flowid); + break; case ETHERTYPE_ARP: Выглядит криво конечно, работает только для ethernet и ipv4, но я нифига не девелопер, и я хз почему это не сделали в базовой системе - штука тривиальная на самом деле, может кто знающий подскажет почему. Ну и по хорошему нужно нормальный патч, ну чтобы там можно было включать-выключать это через sysctl да и рассчет flowid можно дернуть макросами, которые в lagg используются и запостить pr какой-то.