Почему tc не может влиять на формирование? Имеет ли смысл формирование?

В моей работе я обнаружил, что tc может выполнять формирование выхода и может выполнять только контроль доступа. Интересно, почему tc не реализует формирование вхождения?

Пример кода:

#ingress
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 50 \
   u32 match ip src 0.0.0.0/0 police rate 256kbit \
   burst 10k drop flowid :1
#egress
tc qdisc add dev eth0 root tbf \
   rate 256kbit latency 25ms burst 10k

Но я не могу этого сделать:

#ingress shaping, using tbf
tc qdisc add dev eth0 ingress tbf \
   rate 256kbit latency 25ms burst 10k

Я нашел решение, называемое IFB (обновленный IMQ), может перенаправить трафик на выход. Но это не очень хорошее решение, потому что он тратит процессор. Поэтому я не хочу использовать это.

Имеет ли смысл формирование вхождения? И почему tc не поддерживает его?

Ответ 1

Хотя правила формирования tc для входа очень ограничены, вы можете создать виртуальный интерфейс и применить к нему правила выхода, как описано здесь:

https://serverfault.com/questions/350023/tc-ingress-policing-and-ifb-mirroring

(Возможно, вам не нужен виртуальный интерфейс, если ваши виртуальные машины уже используют виртуальные интерфейсы, и вы можете применить к ним tc.)

Предостережение с формированием входящего потока заключается в том, что на входящий поток может потребоваться много времени, чтобы реагировать на ваши действия по формированию из-за всех буферов в маршрутизаторах между источником потока и вашим интерфейсом. И пока поток не отреагирует на уменьшенный предел, он продолжает наводнять ваш нисходящий поток! Тем временем вы будете выбрасывать хорошие пакеты, уменьшая пропускную способность.

Аналогично, когда поток с высоким приоритетом заканчивается или падает, потребуется, чтобы поток с низким приоритетом возвращался к полной скорости. Это может быть довольно разрушительным, если это случается часто!

Результатом этого является то, что динамическое форматирование может работать по желанию для групп устойчивых скоростных долгоживущих потоков, но будет иметь мало преимуществ для короткоживущих или изменяющихся скоростей с высокоприоритетными потоками, когда ваш нисходящий поток затоплен: приоритетные потоки просто затянутся слишком долго, чтобы отступить. Однако классификация и ограничение пакетов с низким и средним приоритетом до статической скорости где-то ниже вашего максимального снижения может быть полезна, чтобы гарантировать по крайней мере некоторое пространство для высокоприоритетных данных.

У меня нет никаких данных об этом, и латентность значительно улучшилась со дня ADSL. Поэтому я думаю, что это может стоить тестирования, если низкая латентность или высокая пропускная способность высокоприоритетных пакетов - это то, чего вы хотите больше, чем общая пропускная способность, и вы можете жить с ограничениями выше.

Как упоминает Janoszen и ADSL HOWTO, потоки могут реагировать гораздо быстрее, если мы можем настроить размер окна TCP как часть формирования.

Поиск TLDP для дальнейших исследований.

Ответ 1

Ответ 2