DemYaN

CONFIG_NO_HZ=y но если используется NET_SCHED, желательно CONFIG_HZ_1000=y, т.к. где-то в коде осталась привязка

хеш-фильтры правильно построены?

в ES4626-SFP нет возможности повесить acl на svi-интерфейс

Цена Xeon-a и i7 мало отличается Есть большое подозрение что Xeon и i7 - маркетинговая стратегия продажи одного и того же процессора а че там подозревать? так оно и есть - i7-9xx есть W35xx

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

+ перевести jhash.h на использование функции lookup3, хеш-функции Дженкинса активно используется в nf_conntrack и sfq + route-кеш перевести на trie

XPS решает проблему (программно), но ему еще далек даже до уровня RPS http://git.kernel.org/?p=linux/kernel/git/...564671aa7c0fd27

+ XPS http://lwn.net/Articles/363338/

интересно, на годовщину патча включат его в ядро :)

2-3 full-view?

и что по ресурсам будет дешевле - смириться с возросшей нагрузкой от больших pps или получить рост нагрузки из-за разбора пакета по string ?

изменил quаntum на 3000, понаблюдаю

Угу. Вылечилось тюнингом ядра. Все не помню, но точно помню что поставил тиклесс. Ну и прооптимизировал создание правил в tc. 1 система no_hz, hrtimers 2 3897 фильтров u32 разбросаны по последнему октету ip-адреса в 256 хеш-таблиц 3 карты вход/выход - i82573, поэтому загружены только 2 ядра, загрузка каждого ядра по softirq в ЧНН под 80%, львиную долю сжирает u32 perf-top: 286.00 - 13.7% : u32_classify [cls_u32] 187.00 - 9.0% : e1000_clean [e1000e] 178.00 - 8.5% : ipt_do_table [ip_tables] 117.00 - 5.6% : e1000_intr_msi [e1000e] 70.00 - 3.4% : ip_route_input 58.00 - 2.8% : htb_dequeue [sch_htb] 40.00 - 1.9% : _spin_lock 34.00 - 1.6% : read_tsc 31.00 - 1.5% : e1000_clean_rx_irq [e1000e] 29.00 - 1.4% : htb_enqueue [sch_htb] 27.00 - 1.3% : nf_iterate 26.00 - 1.2% : iphash_ktest [ip_set_iphash] 25.00 - 1.2% : __nf_conntrack_find [nf_conntrack] 25.00 - 1.2% : _spin_lock_irqsave 23.00 - 1.1% : copy_to_user собственно больше интересует что подразумевает под собой "htb: too many events", что не успевает обработать?

Linux, htb, около 4000 htb-классов. С переходом с версии ядра 2.6.28 на 2.6.32.8 время от времени в логи начали вываливаться сообщения: [ 792.604379] htb: too many events! [ 2777.926380] htb: too many events! [18414.947790] htb: too many events! кто-то с таким сталкивался? кусок кода ответственного кода: /** * htb_do_events - make mode changes to classes at the level * * Scans event queue for pending events and applies them. Returns time of * next pending event (0 for no event in pq, q->now for too many events). * Note: Applied are events whose have cl->pq_key <= q->now. */ static psched_time_t htb_do_events(struct htb_sched *q, int level, unsigned long start) { /* don't run for longer than 2 jiffies; 2 is used instead of 1 to simplify things when jiffy is going to be incremented too soon */ unsigned long stop_at = start + 2; while (time_before(jiffies, stop_at)) { struct htb_class *cl; long diff; struct rb_node *p = rb_first(&q->wait_pq[level]); if (!p) return 0; cl = rb_entry(p, struct htb_class, pq_node); if (cl->pq_key > q->now) return cl->pq_key; htb_safe_rb_erase(p, q->wait_pq + level); diff = psched_tdiff_bounded(q->now, cl->t_c, cl->mbuffer); htb_change_class_mode(q, cl, &diff); if (cl->cmode != HTB_CAN_SEND) htb_add_to_wait_tree(q, cl, diff); } /* too much load - let's continue after a break for scheduling */ if (!(q->warned & HTB_WARN_TOOMANYEVENTS)) { printk(KERN_WARNING "htb: too many events!\n"); q->warned |= HTB_WARN_TOOMANYEVENTS; } return q->now; }

нагрузка хорошо возрастает, когда в школах объявляют карантин :)

"Пожалуй, к 2013 году переход от IPv4 к IPv6 будет почти полностью завершен, пишет Network World." оптимисты :)

Q6600 по сути два 2-ядерника в одной упаковки, соответственно производительность падает при обмене данными между разными ядрами разных процессоров ps линузятник ;)

У нас 720-820байт

а как в них можно посмотреть данные DDM ?

вроде как 512 SVI

Можно и дальше проповедовать, что терминировать cvlan в l3 на агрегации - это грех, что нужно все тянуть в ядро в q-in-q.... хотя нет обязательно MPLS или PBB, которое обязательно на 7750.... Но реальность такова, что функционал unnumbered используют очень много сетей и он эффективен... и если это противоречит религии ALU - это их проблемы, купят у другого вендора. по документации в ALU 6855 и BGP нет... но вы то знаете, что это не так ;) c3560-ipservicesk9-mz.122-44.SE3 interface Loopback2 ip address 10.128.160.1 255.255.255.0 no ip redirects ! interface Vlan178 ip unnumbered Loopback2 no ip proxy-arp ! ip route 10.128.160.10 255.255.255.255 Vl178

Извините, а кому нужен этот сферический конь в вакууме в виде 100% wire-rate с пакетами в 64? Мне к примеру и фабрики как у 3560-E хватит, а в большинстве случаев и 32G 3560G. Если бы все сети планировали архитекторы, то развитие отечественного рынка ШПД было бы на том же уровне что и ядерная энергетика в Буркина Фасо.

В том то и дело, когда стоит задача найти оптимальный по соотношению цена/функционал свитч на агрегацию сразу набегают сейлы от различных производителей, которые предлагают свои enterprise-модели для данной задачи. При этом бьют в грудь, что их девайс не хуже каталиста или пр., но когда задаешь вопросы по функционалу который просто необходим на агрегации - сразу оговорки "ну, это ж enterprise...."...Пока ALU, Edge-Core и прочие думают нужны ли unnumbered/supervlan, операторы продолжают покупают 3560, 3750 (причем тоже enterprise), хоть это и дороже и неудобнее.

Вот ни понимаю, что в этом функционале такого сложно, что большинство производителей игнорируют просьбы операторов добавить оный? Люди покупают каталисты, ставят пачку конвертеров лишь бы эта функция была.

Вопрос по 6580/6855, можно ли на них реализовать функционал аналогичный ip unnumbered или RFC3069 ?