К сожалению никак не сказалось по сути.BQL требует поддержку на уровне драйверов (у нас она есть), но как бы производительности не добавляет оно динамически крутит размер очереди в драйвере т.е. по сути влияет на задержки т.к. раньше очереди были всегда фиксированными и длинными, полезно в паре с fq_codel.
qdisc: bulk dequeue support for qdiscs with TCQ_F_ONETXQUEUE из того же набора по сути оптимизация блокировок в qdisc. Более того не работает с GSO.
net: Make dev_hard_start_xmit() work fundamentally on lists идея ясна но разницы на одноведерном мипсе с микроскопом не нашёл.
На SMP основной профит в новых ядрах по производительности на транзитной пакетомолотилки получился из-за отказа от root блокировки в контрак что позволило его распараллелить. Плюс ещё стопка патчей на схожую тему.
Однако всё это не компенсирует даже одного единственного удаления route cache. Так что пока мы остановились на 3.4 и мониторим как развивается ситуация проверяя каждую значимую ветку. А пока приходиться самостоятельно бэкпортить достаточно много кода в 3.4 ибо не смотря на то что оно LTS и до сих пор поддерживается, но многие критичные фиксы по сети и оптимизации в него не перененесли, вообще в LTS традиционно сети уделяется очень мало внимания.
>Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;
Тут видимо просто забыли добавить на SMP системах. =) Домашний компутер о 8ми 2ГГц x86 с DDR3 рамой и с огромным кэшем головах это далеко не средний или дешовый роутер с ~400-600МГц одноведерным mips 24kc у которого и L2 то кэша нет вообще никакого и рама дай бог DDR1.
