pktgen-dpdk的rfc2544_tput_test.lua脚本在运行RFC2544测试时，默认会以设定的50%速率发送测试包（默认的测试包长是64, 128, 256, 512, 1024, 1280, 1518 ）。假设发包的端口是万兆网卡，那么初始的发包速率是万兆网卡速率的一半发包。通过l2fwd转发包之后pktgen-dpdk会统计本次测试收到的包。如果收包个数等于发包个数，那么RFC2544认为当前的发送速率是可以无丢包完成转发的。这个时候通过二分法进行第二次测试，会以75%的速率发包。如果以75%的速率发包，统计到的收包小于发包的个数，这里就认为有丢包。那么程序就会认为75%的发包速率并不是一个可靠的发包速率。这时就会通过二分法降低发包速率，以62.5%的发包速率进行发包。直到找到一个界限值，该值网上发包速率就会出现丢包，该值往下发包仍然是可以接受的丢包率。在每个包长的转发测试中会用二分法多次测试以确定速率。用以确定被测网络环境的转发性能。
rfc2544_tput_test测试计划参数设置在rfc2544中主要有三个参数来控制每一次的测试时间和时长。
-- Time in seconds to transmit for #这里脚本中注释说是以秒为单位但是实际测试时感觉还是以毫秒为单位。local duration= 10000; #每运行一次测试时运行时间local confirmDuration= 60000; #每轮（这里表示一个包长字节测试完成得出最终速率结果）测试得到满足丢包率下的速率后，脚本会持续的以该速率发送观察是否仍有丢包存在，如丢包率满足设定值，则认为该速率值满足测试结果。local pauseTime= 10000;#每轮测试完成之后在下一论测试开始之前的等待时间。该等待时间主要是为了等待网络链路流量正常。 rfc2544_tput_test脚本缺陷1.在测试时duration的时间和confirmDuration时间需要更具实际情况调试。
过短会造成测试数据不稳定，但时长不是越长越好。当duration时间和confirmDuration时长差距过大时容易导致pktgen-dpdk在测试下一个字节的时候不会发包。
2.rfc2544_tput_test丢包率默认为0。
在理论情况下将丢包率设置为0固然是一件好事。但是在实际情况下由于网络环境实际，原因包括软件发包缺陷，这里很容易导致测试不准确。试想当测试出一个无丢包速率之后，pktgen-dpdk会以该速率持续发包用以确认是否满足收发包低于丢包率。但是rfc2544_tput_test将丢包率设置为0，这样很可能会因为很细小的网络原因导致测试结果无法被确认。
Max rate of 1% could not be confirmed for 60 seconds as required by rfc2544.
3.rfc2544_tput_test测试脚本中二分法的粒度过大。在rfc2544_tput_test中设定min_rate默认为1，所以导致如果你的转发速率真的低于1%，那么很可能就没办法测试。
这里贴出相关代码
local function runThroughputTest(pkt_size)local num_dropped, max_rate, min_rate, trial_rate;max_rate = 100;min_rate = 0.1;#如果想要增加测试精度，这里一定要改小最低速率。trial_rate = initialRate;for count=1, 10, 1donum_dropped = runTrial(pkt_size, trial_rate, duration, count);if num_dropped == 0thenmin_rate = trial_rate;elsemax_rate = trial_rate;endtrial_rate = min_rate + ((max_rate - min_rate)/2);end4.丢包会出现负数的情况。
pktgen-dpdk对发送的包不染色，不打标签，所以接收端会把所有的包转发。所有接受的包都会被统计到pktgen-dpdk中。如果这个网络里有arp，lldp，stp包则都会被统计，所以rx会大于tx。
设置丢包率考虑到0丢包率设置真的对测试很不友好，并且像ixia和sprint仪器都可以设置一个丢包率。这里博主想出了一个笨办法来大致的设置丢包率。
假设丢包率设置为小数点后面五个0的情况。