12月11号 解决dpdk抓包时出现imiss的问题

经现场运维反馈,公司的项目程序日志中存在imiss丢包的情况
一般来说imiss增加,是因为dpdk抓包cpu的抓包能力弱,导致丢包

server代码原来的处理流程是:
抓包->解析数据包的五元组->以一定规则进行hash->hash值投递到不同的slot中

正常情况下,使用cpu的一个核心抓包,单网卡抓包10G是没问题的
但是需要解析数据包的过程以及hash计算,导致server的抓包cpu性能下降,从而导致imiss的产生.

解决办法:
1.提升程序的解析数据包和hash算法的性能
2.使用采用dpdk 的rss算法

解决办法是采用dpdk 的rss算法
步骤1:在DPDK中通过设置rte_eth_conf中的mq_mode字段来开启RSS功能， rx_mode.mq_mode = ETH_MQ_RX_RSS。
struct rte_eth_conf port_conf = {
.rxmode = {
.mq_mode = ETH_MQ_RX_RSS,
//.max_rx_pkt_len = ETHER_MAX_LEN,
.max_rx_pkt_len = SERVER_MAX_PKT_LEN,
.split_hdr_size = 0,
.header_split = 0, /*< Header Split disabled /
.hw_ip_checksum = 0, /*< IP checksum offload disnabled /
.hw_vlan_filter = 0, /*< VLAN filtering disabled /
.jumbo_frame = 0, /*< Jumbo Frame Support disabled /
.hw_strip_crc = 0, /*< CRC stripped by hardware /
},
.rx_adv_conf = {
.rss_conf = {
.rss_key = rss_intel_key,//底层默认采用rss_intel_key
//.rss_hf = ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP |ETH_RSS_TUNNEL,
.rss_hf = ETH_RSS_IP,
},
},
.txmode = {
.mq_mode = ETH_MQ_TX_NONE,
},
};
rss_hf为hash function的标识.
值的组合为:ETH_RSS_IP | ETH_RSS_UDP | ETH_RSS_TCP |ETH_RSS_TUNNEL,
读者可根据项目需求场景,自己选择一个key.

步骤2:当RSS功能开启后，报文对应的rte_pktmbuf中就会存有RSS计算的hash值，可以通过pktmbuf.hash.rss来访问。 这个值可以直接用在后续报文处理过程中而不需要重新计算hash值，如快速转发，标识报文流等

步骤3:对称hash key寻找
在网络应用中，如果同一个连接的双向报文在开启RSS之后被分发到同一个CPU上处理，这种RSS就称为对称RSS。 如果同一个连接的双向报文被分发到不同的CPU，那么两个CPU之间共享这个连接的信息就会涉及到锁，而锁显然是会影响性能的。

经过测试,dpdk使用的默认hash key不是对称hash key,在网上找了一圈,最后在一个英文博客中,找到了一个对称rss hash key.
static uint8_t rss_intel_key[40] = {
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, 0x6D, 0x5A,
0x6D, 0x5A, 0x6D, 0x5A, };

RETA是运行时可配置的，这样应用程序就可以动态改变CPU对应的接收队列，从而动态调节报文分发。 具体通过PMD模块的驱动进行配置，例如ixgbe_dev_rss_reta_update和ixgbe_dev_rss_reta_query。

现在抓包时的imiss问题是解决了,但是每个槽的数据量依旧分布的不均匀!这个得想个好的算法来解决下.