最近遇到一个问题，当tcp收包的时候，我们的服务器的入向软中断比例很高。

我们知道，napi模式，可以降低收包入向软中断占比，那么，针对napi模式，能不能优化？本文针对2.6.32-358内核进行分析：

static void net_rx_action(struct softirq_action *h){    struct list_head *list = &__get_cpu_var(softnet_data).poll_list;    unsigned long time_limit = jiffies + 2;    int budget = netdev_budget;----------------这个值可以通过/proc/sys/net/core/netdev_budget修改，默认是300    void *have;    int select;    struct rps_remote_softirq_cpus *rcpus;    local_irq_disable();    while (!list_empty(list)) {-------------------不为空，则一直循环        struct napi_struct *n;        int work, weight;        /* If softirq window is exhuasted then punt.         * Allow this to run for 2 jiffies since which will allow         * an average latency of 1.5/HZ.         */        if (unlikely(budget <= 0 || time_after(jiffies, time_limit)))----------时间到，或者配额到了，则退出循环。            goto softnet_break;        local_irq_enable();        /* Even though interrupts have been re-enabled, this         * access is safe because interrupts can only add new         * entries to the tail of this list, and only ->poll()         * calls can remove this head entry from the list.         */        n = list_first_entry(list, struct napi_struct, poll_list);        have = netpoll_poll_lock(n);        weight = n->weight;--------------napi配置的weight，这个是一次poll的配额，和上面总的配合一起控制收包，这个在netif_napi_add 函数中设置。

/* This NAPI_STATE_SCHED test is for avoiding a race * with netpoll's poll_napi(). Only the entity which * obtains the lock and sees NAPI_STATE_SCHED set will * actually make the ->poll() call. Therefore we avoid * accidently calling ->poll() when NAPI is not scheduled. */ work = 0; if (test_bit(NAPI_STATE_SCHED, &n->state)) { work = n->poll(n, weight);------------回调poll，不同的厂家有不同的实现，比如intel的ixgbe_poll实现 trace_napi_poll(n); } WARN_ON_ONCE(work > weight); budget -= work; local_irq_disable(); /* Drivers must not modify the NAPI state if they * consume the entire weight. In such cases this code * still "owns" the NAPI instance and therefore can * move the instance around on the list at-will. */ if (unlikely(work == weight)) { if (unlikely(napi_disable_pending(n))) { local_irq_enable(); napi_complete(n); local_irq_disable(); } else list_move_tail(&n->poll_list, list); } netpoll_poll_unlock(have); } out: rcpus = &__get_cpu_var(rps_remote_softirq_cpus); select = rcpus->select; rcpus->select ^= 1; local_irq_enable(); net_rps_action(&rcpus->mask[select]); #ifdef CONFIG_NET_DMA /* * There may not be any more sk_buffs coming right now, so push * any pending DMA copies to hardware */ dma_issue_pending_all(); #endif return; softnet_break: __get_cpu_var(netdev_rx_stat).time_squeeze++; __raise_softirq_irqoff(NET_RX_SOFTIRQ); goto out; }

 从代码可以看出，限制一次调用net_rx_action的地方，无非是时间，还有netdev_budget，如果把netdev_budget 调大，是不是就可以一次性多收一点包呢，意味着触发软中断的次数就会减少，答案是肯定的。

那么默认值来看，netdev_budget 比napi配置的weight要大。

/* initialize NAPI */

netif_napi_add(adapter->netdev, &q_vector->napi,ixgbe_poll, 64);-------传入64

void netif_napi_add(struct net_device *dev, struct napi_struct *napi,            int (*poll)(struct napi_struct *, int), int weight){    INIT_LIST_HEAD(&napi->poll_list);    napi->gro_count = 0;    napi->gro_list = NULL;    napi->skb = NULL;    napi->poll = poll;    if (weight > NAPI_POLL_WEIGHT)        pr_err_once("netif_napi_add() called with weight %d on device %s\n",--------会打印，但是也不会限制                weight, dev->name);    napi->weight = weight;    list_add(&napi->dev_list, &dev->napi_list);    napi->dev = dev;#ifdef CONFIG_NETPOLL    spin_lock_init(&napi->poll_lock);    napi->poll_owner = -1;#endif    set_bit(NAPI_STATE_SCHED, &napi->state);

我们通过将传入的64改大到256，因为在ixgbe_poll 函数中，这个值控制了一次循环收包的个数。

int ixgbe_poll(struct napi_struct *napi, int budget){    struct ixgbe_q_vector *q_vector =                container_of(napi, struct ixgbe_q_vector, napi);    struct ixgbe_adapter *adapter = q_vector->adapter;    struct ixgbe_ring *ring;    int per_ring_budget;    bool clean_complete = true;#ifdef CONFIG_IXGBE_DCA    if (adapter->flags & IXGBE_FLAG_DCA_ENABLED)        ixgbe_update_dca(q_vector);#endif    ixgbe_for_each_ring(ring, q_vector->tx)----------------------遍历tx队列，跟本文讨论的内容不相关，本文讨论收包        clean_complete &= !!ixgbe_clean_tx_irq(q_vector, ring);    if (!ixgbe_qv_lock_napi(q_vector))        return budget;    /* attempt to distribute budget to each queue fairly, but don't allow     * the budget to go below 1 because we'll exit polling */    if (q_vector->rx.count > 1)        per_ring_budget = max(budget/q_vector->rx.count, 1);---通过增大 budget，从64改大到256，增加了一次循环收包的个数    else        per_ring_budget = budget;    ixgbe_for_each_ring(ring, q_vector->rx)-----------遍历收包队列，        clean_complete &= (ixgbe_clean_rx_irq(q_vector, ring,                   per_ring_budget) < per_ring_budget);    ixgbe_qv_unlock_napi(q_vector);    /* If all work not completed, return budget and keep polling */    if (!clean_complete)        return budget;    /* all work done, exit the polling mode */    napi_complete(napi);    if (adapter->rx_itr_setting & 1)        ixgbe_set_itr(q_vector);    if (!test_bit(__IXGBE_DOWN, &adapter->state))        ixgbe_irq_enable_queues(adapter, ((u64)1 << q_vector->v_idx));    return 0;}

通过将 budget 从64改大到256，同样的入向流量，软中断从25%降低到23%，效果很明显。

那么，能否无限制改大呢，显然不行，一则是改大后，各个队列收包就很难均衡，因为每个队列收完对应的报文之后（除非收空了），才能返回，这样，就关中断时间太长了。

可能有人会问，这个改大收包个数，但是处理软中断的总时间应该没变化，为什么会降低呢，取个极限的例子，napi出来就是应对以前单个包就需要一个中断的问题的，所以单次收包

多一些应该是有用的。

除此之外，通过设置网卡的rx-usecs属性，将这个值改大些，也可以降低软中断的占比。

ethtool -c eth0Coalesce parameters for eth0:Adaptive RX: off  TX: offstats-block-usecs: 0sample-interval: 0pkt-rate-low: 0pkt-rate-high: 0rx-usecs: 1-------------默认是1，改成512 ethtool –C eth0 rx-usecs 512

 这个减少了硬中断的触发次数，但是呢，显而易见的是，增加了延迟，如果你的系统是要求实时性极高的，可能要减少该值。

第三个方法就是开启gro了，gro开启之后，收包的时候，如果是同一个流的包，且网卡支持gro属性的话，根据协议的回调会尝试进行合并报文，当前由于目前这个流的宏值

只有最多8个流，超过的会直接送上协议栈，不会合并。当然如果是服务器，发包为主的话，其实gro是有害无益的，因为目前的flow个数限制太多，而且对于tcp来说，ack的报文也不会合并。

所以如果是服务器端，要定制化自己的gro，比如使用hash链来管理flow，使用ack合并来减少软中断消耗。