近期在万兆网卡上測试，出现了之前千兆网卡没有出现的一个现象，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的处理能力有关。