netback的tasklet调度问题及网卡丢包的简单分析

最近在万兆网卡上测试,出现了之前千兆网卡没有出现的一个现象,tasklet版本的netback下,vm进行发包测试,发现vif的interrupt默认绑定在cpu0上,但是vm发包运行时发现host上面cpu1, cpu2的ksoftirqd很高。


从之前的理解上来说,包从netfront出来通过eventchannel notify触发vif的irq处理函数,然后tasklet_schedule调用tx_action,通过一系列处理流程把包发给网卡。所以vif的interrupt绑在哪个cpu上,发包的时候,那个cpu的si%高才对。


仔细查看tasklet的代码发现,除了interrupt处理函数里面会调用tasklet_schedule之外,还有一个地方会调用,就是netif_idx_release, 这个是配合grant map使用的一个回调函数。当skb从网卡发出之后,kfree_skb时候,会调用page注册的一个回调,告诉netback,这个skb发送完成了,你可以给netfront 发送response了,然后顺便tasklet_schedule一把。


所以从这里,就不难看出,cpu1, cpu2上softirq高,tasklet也高, 是因为网卡中断都在cpu1, cpu2上。


开始我有点犯傻,觉得tx的时候,怎么会触发网卡中断呢,不应该是rx的时候才有的。后来看了igb的驱动,才发现真的傻。


网卡发完包,得把skb回收啊,这个时候,就是通过触发之前request_irq的函数来完成的,收包发包都走这一个函数。


就拿线上万兆网卡ixgbe来说


中断处理函数是ixgbe_msix_clean_many,里面调用napi_schedule, 走到ixgbe_poll。这个函数就是我们上面提到的收包发包都在这个里面处理的。


它会先调用ixgbe_clean_tx_irq, 对之前tx发送的包进行回收处理(ixgbe_unmap_and_free_tx_resource),接着调用ixgbe_clean_rx_irq


这个里面会rx_ring里面的rx_buffer_info包括的skb,调用协议栈的收包函数,扔给上层处理,ixgbe_receive_skb->napi_gro_receive->netif_receive_skb


这个rx_ring的count在网卡驱动加载时默认是1024,我们设置了最大上限4096个,是驱动里面每次接收完一批包的时候,就会ixgbe_alloc_rx_buffers 分配一批新的skb和page

pci_dma映射好给硬件去收包


这里第一个tasklet调度到cpu1, cpu2的问题就能解释, vm发包触发了网卡的cpu1, cpu2上的中断,一直到软中断,kfree_skb,触发idx_release,接着tasklet_schedule, 然后tx_action就一直在这两个cpu上,然后vif发包下来触发中断的时候,调用maybe_schedule_tx_action,里面会判断当前pending是否小于max/2,如果小于才去调用tasklet_schedule,这样即使被调用,可能tasklet已经在运行了。为什么之前千兆网络没怎么出现,可能是因为idx_release被调用的变快了吧,没去确认,这已经不重要了。


刚好还有一个网卡丢包的问题,跟网卡驱动有点关系,有个测试发现物理口收了14w的包,丢了45w的包,ethtool -S 看到的话是rx_fifo_errors, 这大概就表明因为没有buffer导致的。刚刚上面也讲到rx_buffer,是在处理完一批请求之后再去分配一批新的buffer,总共就4096个。如果cpu处理变慢,那么外面大压力发过来的情况下,就会有很多丢包,跟cpu的处理能力有关。



netback的tasklet调度问题及网卡丢包的简单分析,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。