linux - 为什么 tc 不能做 ingress shaping？入口整形有意义吗？

Question

在我的工作中，我发现 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 不支持它？

Answer 1

虽然入口的 tc 整形规则非常有限，但您可以创建一个虚拟接口(interface)并将导出规则应用于它，如下所述:

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

(如果您的 VM 已经使用虚拟接口(interface)并且您可以将 tc 应用于它们，则您可能不需要虚拟接口(interface)。)

入口整形的警告是，由于流源和接口(interface)之间的路由器中的所有缓冲区，传入流可能需要很长时间才能响应您的整形操作。在流确实响应减少的限制之前，它将 continue to flood你的下游!同时，您将丢弃好的数据包，从而降低吞吐量。

同样，当高优先级流结束或下降时，低优先级流需要一些时间才能恢复到其全速率。如果经常发生，这可能会造成很大的破坏!

这样做的结果是，动态整形可能会按需要对稳定速率的长生命周期流组起作用，但是当您的下游被淹没时，动态整形对生命周期短或可变速率的高优先级流几乎没有优势:低-优先流将花费太长时间才能退出。然而，将低优先级和中优先级数据包分类并限制为低于最大下降率的静态速率可能会有所帮助，以保证至少为高优先级数据提供一些空间。

我没有这方面的任何数据，自从 ADSL 时代以来，延迟已经改善了很多。所以我认为这可能值得测试，如果高优先级数据包的低延迟或高吞吐量比总吞吐量更重要，并且您可以忍受上述限制。

正如 Janoszen 和 ADSL HOWTO 所提到的，如果我们可以将 TCP 窗口大小作为整形的一部分进行调整，则流可以更快地响应。

Search TLDP进一步研究。