Hqos限速误差太大了，遭投诉了！

vpp项目中hqos功能从20.01版本以后不再支持，20.05版本中虽然hqos的代码还存在，但是在编译列表注释掉了。从20.05版本之后hqos相关的代码已经全部删除掉了。

在vpp-dev邮件列表中有询问最新的vpp版本是否有支持hqos的计划？给的答复是无支持计划。翻阅了一下历史邮件中，主要考虑到Hqos与vpp集成存在架构的问题，目前推荐使用qos策略。

DPDK HQOS如何与VPP集成存在架构问题。 它不是原生代码，可以在VPP图的任意位置使用。 相反，它被绑定到特定的dpdk接口。 使它在每个会话的QoS下工作将是困难和混乱的。 在VPP中拥有HQoS将是一个很好的补充，但它需要通过不同的特性来重用本地代码，在这些特性中QoS策略可以应用到子接口、隧道口、bond接口或物理接口。 在VPP中扩展现有的本地代码策略可能比尝试在VPP中使用DPDK QoS更有意义。 https://lists.fd.io/g/vpp-dev/topic/76548200#17309

国外SDwan开源厂家flexiWAN，提交的特性开发计划列表中有计划支持Hqos功能？flexiWAN目前最新的代码是基于vpp 21.01版本。其开源项目代码库中已经创建了hqos分支：wan-hqos，期待第二季度的发布。

Advanced QoS Q2/2022 https://docs.flexiwan.com/overview/feature-desc.html

基于vpp19.01版本，在应用hqos功能后，实际接收速率要远低于hqos限速的速率大小。在云计算应用场景中，主要与小带宽限速为准，一般用户限速大小在10M左右。本文基于限速速率6M大小下，分别对比在普通物理接口及隧道接口下，两者的误差数值及限速效果。

首先需要了解hqos和policer特性在vpp流程中限速的位置点及限速点的长度是如何确定的？

1、policer限速是基于接口的，支持普通物理口和隧道接口，限速时是以报文在当前接口的长度来限速的，和接口的类型有关系。比如普通物理口组成（eth_hdr(14)+ip_hdr(20)+payload_len）,而ipsec接口是三层口无二层头信息，限速只有（ip_hdr(20)+payload_len）。

隧道接口限速一般是在报文封装之前针对原始报文进行限速的，也就是说ipsec接口限速是在ipsec封装之前进行限速的。

2、Hqos限速是在物理接口tx的时候，调用dpdk hqos模块实现的。和报文的业务场景存在关系。普通三层报文场景时，限速长度为：（eth_hdr(14)+ip_hdr(20)+payload_len），而ipsec场景时，限速长度是ipsec封装后的长度。限速长度如下：

1、基于普通物理接口：

普通物理口在转发中Hqos和policer限速报文长度是一样的，可以直接看不同报文长度下速率效果对比（本文使用iperf3工具）。

说明：

1、iperf3 发包和收包的速率只记录报文payload长度，不包含eth header、ip header及udp header长度（共计42字节）

2、Policer和Hqos限速时报文长度包含eth header、ip header及udp header长度（共计42字节）

3、Policer收包在1400字节时，实际不到6M，是因为iperf3和policer速率统计报文长度不一致影响的。

以1400字节为例，限速长度1442，iperf3速率5.81，理论上包含eth header、ip header及udp header长度（共计42字节）限速速率：1442*5.81/1400 = 5.9842Mbit/s。所以policer限速还是很准确的。

通过上述对比图我们可以得到下面结论：

1、限速的准确性和发包包长有一定的关系，包长越大，限速准确度越高。

包长在800字节以上，policer的限速准确率还是比较准确的。

2、Hqos限速后实际大小比policer低16%左右。需要在Hqos配置速率时进来补偿。

下面是对hqos进行限速大小16%的补偿后的效果对比图：

Hqos速率补偿后，报文长度在442以上，限速效果和qos策略效果差异不大。

2、基于ipsec隧道接口

Ipsec业务在Hqos和policer限速时报文不一致。我们以报文长度142字节为例：

原始报文长度组成：（eth（14）+ip（20）+udp（8）+payload（100））

Policer限速长度：128：（ip（20）+udp（8）+payload（100））

ipsec接口无二层头信息

Hqos限速长度 214字节 ，这个长度无法固定和报文长度，压缩算法都有关系。

下表是基于普通物理口补偿16%后的测试数据:

对比了policer收包和Hqos收包的误差，对比后平均补偿误差在1.09。所以实际补偿误差=1.09*1.16=1.264，设定补偿误差为1.26。Hqos功能使能在ipsec接口时补偿数值按照1.26进行补偿。

通过上面的曲线对比图，我们可以很明显的看出，hqos针对隧道报文的限速误差是相当大的，并且限速下误差和实际报文的长度也有很大的关系的。

最理想的方案是dpdk hqos的api接口中支持设置报文限速长度，以实际原始报文长度来进行限速。

在实际测试中发现，hqos最小的限速力度应该在1M，低于1M时，会导致hqos功能失效，业务断流。 Hqos框架是在接口tx接口中完成的，导致存在一个问题，接口流量统计感知不到hqos的丢包的。就会导致接口速率不准确问题。

在HQOS使用过程中，还有什么其他的问题，欢迎公众号留言，一起交流学些。