tls1.3 грядёт...

813

у меня иксов и всего что с этим связано практически нет

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

873 — кед нет. Есть i3wm.

ну для скромного десктопа, в районе 1к вполне стандартное число, все вот эти несколько сотен, это обычно серваки, да там можно во многое не попадать

именно так

с другой стороны вот тот же свежий ssl почти приёдётся прикручивать, хоть сбоку

с другой стороны вот тот же свежий ssl почти приёдётся прикручивать, хоть сбоку

да, было кто-то в зависимостях требовал версию свежее... даже libressl кто-то один раз запросил....

но это как-то давно очень было

Мда. В режиме рутера энкапсуляция-декапсуляция в gif ещё дороже. Совсем ПЦ :-(

Стыдно прямо такие числа показывать

Мда. В режиме рутера энкапсуляция-декапсуляция в gif ещё дороже. Совсем ПЦ :-(

всмысле ip в ip?

всмысле ip в ip?

Да. Впрочем, gre не дешевле. Та же фигня.

кажется единственная дешевая энкапсуляция это vxlan если ее умеет чип

все остальное смертельно дорого

кажется единственная дешевая энкапсуляция это vxlan если ее умеет чип

Вот я и пытаюсь понять — почему. Ну блин, заголовок в 40 байт навесить в цепочку mbuf'ов. Ну, серьёзно?

При этом с mtu=8192 поверх физики с mtu=9000 — вообще как нету

Вот я и пытаюсь понять — почему. Ну блин, заголовок в 40 байт навесить в цепочку mbuf'ов. Ну, серьёзно?

оффлоады, сегментация?

оффлоады, сегментация?

да фигня всё это, если на физике это отключить скорость падает на 10%.

(на физике)

Ну то есть, приятно, 10%, но не в три раза же

И, главное, если уменьшать mtu постепенно то скорость падает не равномерно а скачком в какой-то момент. Именно это меня заставляет думать, что там что-то не так

а) в какой момент б) я пропустил у тебя конжешен какой кстати? или ты не tcp гоняешь

а) в какой момент б) я пропустил у тебя конжешен какой кстати? или ты не tcp гоняешь

Примерно на 2048 байтах. После этого там потери относительно физики малоизмеримы. Конжешн стандартный ньюрено на одном конце и что там у винды на другом

(50 is the default transmit queue length on FreeBSD.)

(50 is the default transmit queue length on FreeBSD.)

Как оно в новом iflib'е зовётся-то, что-то не найти толком…

Вот я и пытаюсь понять — почему. Ну блин, заголовок в 40 байт навесить в цепочку mbuf'ов. Ну, серьёзно?

основная потеря производительности идёт из-за удлинения цепочки вызовов. У тебя же двойной проход по IP стеку, сначала для outer заголовка, потом для inner - это на входе. На выходе - наоборот.

основная потеря производительности идёт из-за удлинения цепочки вызовов. У тебя же двойной проход по IP стеку, сначала для outer заголовка, потом для inner - это на входе. На выходе - наоборот.

Это понятно, что удлиннение. Но нет ли там в этой удлинённой цепочке проблемы с локами, вот что я пытаюсь понять. потому что там если увеличивать MTU скачок есть. А не поавный рост до конца. Хотя это может быть просто процессор раз-насытился.

мы используем direct vlan патч, который укорачивает цепочку вызовов на входе путём пропускания vlan_* обработки и прямо из драйвера сетевой карты идёт в ethernet. Это даёт прироста производительности примерно на 15%

основная потеря производительности идёт из-за удлинения цепочки вызовов. У тебя же двойной проход по IP стеку, сначала для outer заголовка, потом для inner - это на входе. На выходе - наоборот.

Ну и да, ну вдвое длиннее цепочка — это latency больше. Окно должно съесть.

Хотя, судя по тому, что UDP мелкими пакетами не зависит от MTU, просто процессор упирается в PPS

тут скорее дело в кешировнии

когда длинная цепочка вызовов, процессор обращается всё время к разным данным

на кешировании бОльшей частью мы выигрываем при fastforwarding'е

и это прямо ЗАМЕТНО как tryforward код быстрее работает чем обычный ip forwarding

Ну, проблема с локальностью кешей в такой ситуации известно как решается — батчить вызовы. latency выше, throughput тоже выше Но, боюсь, это весть стек надо переписать

у нас так же в некоторых местах есть декапсуляция трафика не средствами gif, а средствами pfil

т.е. трафик декапсулируется и роутится прямо в ethernet хуке минуя весь IP стек

это тоже громадно снижает нагрузку на машину

Нифига себе!

VPN через firewall :-)

Апстримить не хотите? Мне кажется, ip-in-ip И gre это такие штуки, которые неплохо бы максимально оптимизировать кастомно, а не что бы они общим путём шли.

приходится идти на всякие ухищрения, когда IPv6-only ДЦ хочет общаться с IPv4 миром

Жалко, я NAT отколючить не могу для чистоты эксперимента.

ipv4 over ipv6)

кстати, неоптимальность правил файрвола тоже может сильно влиять

но я сомневаюсь, что у тебя какой-то развесистый файрвол

кстати, неоптимальность правил файрвола тоже может сильно влиять

На флеймграфе — максимум 5%

но я сомневаюсь, что у тебя какой-то развесистый файрвол

ну, не минимальный, но я старалася.

Можно, конечно, попробовать нарисовать совсем минимальный из одного правила про nat

или отключить десктоп от общей сети и воткнуть прямо в DUT и чёрт с ним с интернетом, но тогда тесты все придётся гонять локально совсем и даже елси что в доку не подглядеть.

Интересно, есть ли в Питере фирмы, могущие попробовать починить супермикровскую мать, которая просто перестала запускаться…

я бы себе ещё один комп собрал…

(проблема в том, что для диагностики нужен другой совместимый процессор и DDR3-ECC память, а это всё не в каждом ремонтном подвале есть)

>Network hardware (even in cheap hardware!) has grown “smart”, with offload engines of various sorts. Modern network hardware has often sprouted various “offload” engines, unfortunately now often enabled by default, which tend to do more damage than good except for extreme benchmarking fanatics, often primarily on big server machines in data centers.

Кстати, а в ipfw-таблчику где ключом инт ерфейс, можно имя со звёздочкой класть, как в правиле? gif*?

нет

А source-based routing'а у нас нет? Без ipfw fwd?

setfib?

setfib?

На что?

Эм. На интерфейс.

Хм.

Это мысль, позволит, кажется, избавится для тестов от nat.

в ipfw в качестве протокола можно tcp4 указывать же? (чтоб v6 не попадало в правило)

нет

О. Вот ещё вопрос: nat + ipsec в транспортном режиме — no luck?

Или я что-то не так делаю?

У меня есть полиси всё tcp между 10.0.0.1 и 10.0.0.2 шифровать в транспортном режиме

Это работает если я прямо с хоста 10.0.0.1 ижду на 10.0.0.2 — всё шифруется, всё расшифровывается

Но 10.0.0.1 — раутер. И там есть nat с 10.0.0.1 как "внешним" адресом

И вот судя по всему, пакеты после nat прямо улетают в интерфейс, потому что 10.0.0.2 видит их незашифрованными

И, конечно, дропает

в ip_output pfil вызывается после ipsec

имей это ввиду

ЭхЪ

Да, это всё объясняет

для извращенцев есть if_enc

используя if_enc ты можешь занатить пакет во время ipsec обработки

используя if_enc ты можешь занатить пакет во время ipsec обработки

Я туплю — как?!

if_enc может добавить два вызова pfil изнутри ipsec

http://bu7cher.blogspot.com/search/label/if_enc

А, всё, сообразил.

Ага.

Не, нафик.

Не буду бенчмаркать этот режим просто

Всё равно он не реалистичный совершенно

NAT + IPSec в транспортном (а не туннельном!) режиме это врядли вообще где-то используется

ты недооцениваешь людей

:-)

я когда-то отломал какую-то штуку там внутри ipsec, как мне казалось что так не бывает

на следующий день мне написал dadv и сказал что я ему сломал роутер

у него там была хитрая конфигурация с натом

а кто-нибудь в курсе, ящики с пожарной сигнализацией в подъездах многоквартирных домов, там есть какие-нибудь датчики на открытие их?

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

да вы там похоже просто много кушаете, в вмысле зажрались, ящик пожарной сигнализации у него понимаш ли :) а так чего не открыть, если не написано обратного :)

NAT + IPSec в транспортном (а не туннельном!) режиме это врядли вообще где-то используется

тут люди предлагали ip-ip инкапсуляцию + transport mode.

чтобы роутить по интерфейсам

Ну, это другое всё же.