网卡收包API选取
DPDK的i40e驱动中为710网卡提供多个收包接口，分别是：
i40e_recv_scattered_pkts_vec
i40e_recv_scattered_pkts
i40e_recv_pkts_vec
i40e_recv_pkts_bulk_alloc
i40e_recv_pkts
具体使用哪个接口由当前网卡接口的配置来决定，也就是下面三个变量
rx_vec_allowed、scattered_rx以及rx_bulk_alloc_allowed决定，具体逻辑如下：
- scattered_rx：跟超长帧和mbuf数据去长度有关，当配置的网卡超长帧大于一个mbuf能够承载的数据时，也就是一个报文可能分布在两个mbuf中时，scattered_rx被置为1，若网卡配置的超长帧不大于一个mbuf的数据区长度2048，可以设置scattered_rx为0，在scattered收包接口中（i40e_recv_scattered_pkts_vec和i40e_recv_scattered_pkts），需要额外处理大报文的mbuf的链接问题。
- rx_vec_allowed：是否允许向量收包，在向量收包的接口中，使用了CPU支持的sse指令，批量化的处理描述符相关的数据，一次能够操作4个描述符或者mbuf，收包性能比较好，但是当网卡使能了1588、FDIR以及QINQ功能时，DPDK中默认不允许向量收包，既将rx_vec_allowed置为0。这是因为，使能了上述offload功能后，网卡收包时会将1588时间戳、FDIR的规则id、以及剥掉的QINQ外层vlan写到网卡的描述符中，同时在非向量收包接口中将上述信息解析写到mbuf的控制结构中以供上层应用软件使用。但是向量收包函数中，没有处理上述信息，故而DPDK在检测到网卡开启上述功能后，会将rx_vec_allowed置0。
- rx_bulk_alloc_allowed：这个变量只有在一些极端情况下才会被置0，比如rx_free_thresh配置小于32，或者rx_free_thresh比网卡描述符个数还要大，一般设置该变量为1。
所以，一般情况下i40e_recv_pkts_vec性能应该优于i40e_recv_pkts_bulk_alloc。不过使用i40e_recv_pkts_vec会带来软件处理数据包时无法获取FDIR的全部信息
收发队列长度配置
收包队列长度
收包队列的长度就是每个收包队列分配的收包描述符个数， 每个收包描述符都会分配有对应的Mbuf缓存块。 收包队列的长度就表示了在软件驱动程序读取所收到的包之前最大的缓存包的能力， 长度越长， 则可以缓存更多的包， 长度越短， 则缓存更少的包。 而网卡硬件本身就限定了可以使用的最大的队列长度。 收包队列长度太长， 则需要分配更多的内存缓存块（ Mbuf） ， 需要占用更多地资源， 同时Mbuf的分配和释放可能需要花费更多的处理时间片。 收包队列太短， 则为每个队列分配的Mbuf要相对较少， 但是有可能用来缓存收进来的包的收包描述符和Mbuf都不够， 容易造成丢包。 可以看到DPDK很多示例程序里面默认的收包队列长度是128， 这就是表示为每一个收包队列都分配128个收包描述符， 这是一个适应大多数场景的经验值。 但是在某些更高速率的网卡收包的情况下， 128就可能不一定够了， 或者在某些场景下发现丢包现象比较容易的时候， 就需要考虑使用更长的收包队列， 例如可以使用512或者1024。
发包队列长度
发包队列的长度就是每个发包队列分配的发包描述符个数， 每个发包描述符都会有对应的Mbuf缓存块， 里面包含了需要发送包的所有信息和内容。 与收包队列的长度类似， 长的发包队列可以缓存更多的需要发送出去的包， 当然也需要分配更多的内存缓存块（ Mbuf） ， 占用更多的内存资源； 而短的发包队列则只能缓存相对较少的需要发送出去的包， 分配相对较少的内存缓存块， 占用相对较少的内存资源。 发包队列长， 可以缓存更多的包， 不会浪费网卡硬件从内存读取包及其他信息的能力， 从而可以更充分利用硬件的发包能力。 发包队列短， 则可能会发生网卡硬件在发送完所有队列的包后需要等待一定时间来让驱动程序准备好后续的需要发出去的包， 这样就浪费了发包的能力， 长期累积下来， 也是造成丢包的一种原因。 可以看到DPDK的示例程序里面默认的发包队列长度使用的是512， 这就表示为每一个发包队列都分配512个发包描述符， 这是一个适用大部分场合的经验值。 当处理更高速率的网卡设备时， 或者发现有丢包的时候， 就应该考虑更长的发包队列， 例如1024。
