flow director
将网卡的某个接收队列分配给某个核,从该队列中收到的所有报文都应当在该指定的核上处理结束。
从核对应的本地存储中分配内存池,接收报文和对应的报文描述符都位于该内存池。
为每个核分配一个单独的发送队列,发送报文和对应的报文描述符都位于该核和发送队列对应的本地内存池中。
可以看出不同的核,操作的是不同的队列,从而避免了多个线程同时访问一个队列带来的锁的开销。但是,如果逻辑核的数目大于每个接口上所含的发送队列的数目,那么就需要有机制将队列分配给这些核。不论采用何种策略,都需要引入锁来保护这些队列的数据。
网卡是如何将网络中的报文分发到不同的队列呢?常用的方法有微软提出的RSS与英特尔提出的Flow Director技术,前者是根据哈希值希望均匀地将包分发到多个队列中。后者是基于查找的精确匹配,将包分发到指定的队列中。此外,网卡还可以根据优先级分配队列提供对QoS的支持。
网卡上存储了一个Flow Director的表,表的大小受硬件资源限制,它记录了需要匹配字段的关键字及匹配后的动作;驱动负责操作这张表,包括初始化、增加表项、删除表项;网卡从线上收到数据包后根据关键字查Flow Director的这张表,匹配后按照表项中的动作处理,可以是分配队列、丢弃等。
它更加强调特定性。比如,用户可以为某几个特定的TCP对话(S-IP+D-IP+S-Port+D-Port
)预留某个队列,那么处理这些TCP
对话的应用就可以只关心这个特定的队列,从而省去了CPU
过滤数据包的开销,并且可以提高cache
的命中率。
Perfect match filters. The hardware checks a match between the masked fields of the
received packets and the programmed filters. The masked fields are for IP flow.
• Signature filters. The hardware checks a match between a hash-based signature of the
masked fields of the received packet.
关于RSS
rss 是网卡提供的分流机制
**rte_softrss_be/rte_softrss两个函数可以软件计算出来跟硬件rss一样的结果;
**rss_key使用default的key不能保证同一条会话的双向flow的hash结果一致,使用对称的rss key可以解决这个问题。下述文章推荐了一个离散度好的对称rss key。
static uint8_t hash_key[RSS_HASH_KEY_LENGTH] = { 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, };
DPDK Design Tips (Part 1 - RSS) · GalSagie