最近在万兆网卡上测试，出现了之前千兆网卡没有出现的一个现象，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调度问题及网卡丢包的简单分析,布布扣,bubuko.com