在我的工作中，我发现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)的解决方案可以将流量重定向到导出。但这似乎不是一个好的解决方案，因为它浪费了CPU。所以我不想用这个。
入口整形是否有意义？为什么tc不支持它？
最佳答案
尽管用于入口的tc整形规则非常有限，但是您可以创建一个虚拟接口(interface)并对其应用导出规则，如下所述:
(如果您的VM已经使用虚拟接口(interface)，则可以不需要虚拟接口(interface)，并且可以将tc应用于虚拟接口(interface)。)
关于入口整形的警告是，由于流源和接口(interface)之间的路由器中的所有缓冲区，传入流可能需要很长时间才能响应您的整形 Action 。直到流确实响应减少的限制，它才会向下游continue to flood!同时，您将丢弃好数据包，从而降低吞吐量。
同样，当高优先级流结束或中断时，低优先级流又要花一些时间才能恢复到其全速率。如果经常发生，这可能会造成很大的破坏!
这样的结果是，动态整形可能对于稳定速率的长寿命流组可以按期望的方式工作，但是当下游被洪水淹没时，对于短期或可变速率的高优先级流将没有太大优势:低优先级流将只是花了太长时间才退缩。但是，将中低优先级数据包分类并限制为低于最大降低速率的静态速率可能会有所帮助，以确保为高优先级数据至少保留一些空间。
我对此没有任何数据，自ADSL时代以来，延迟已大大改善。因此，我认为值得一试，如果低延迟或高优先级数据包的高吞吐量比整体吞吐量需要的更多，并且您可以承受上述限制。
正如Janoszen和ADSL HOWTO所提到的，如果我们可以在调整过程中调整TCP窗口大小，则流可以更快地响应。
Search TLDP有待进一步研究。
关于linux - 为什么TC无法进行入口整形？入口整形是否有意义？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/15881921/