linux tcp重傳多會導致軟中斷在各個核很不均勻么？

網絡不穩定，會導致某些核的軟中斷很高么?那么，下面我們來分析下這個論斷的准確性。

環境描述：

網卡軟中斷進行了綁核。設備具備80個核，960個網卡中斷，沒開啟bbr，全部是tcp呼叫。

# cat /proc/cpuinfo |grep processor|wc -l
80

# cat /proc/interrupts |grep   eth |wc -l
960

# cat /proc/irq/848/smp_affinity
00000000,00000000,00000000,00000000,00008000,00000000,00000000

每個網卡中斷指定在一個cpu核上。

問題描述：發現有的核上軟中斷比其他核高很多，因為當時看到有大概2個點的重傳率。

分析過程：

首先，重傳的報文數量，確實有可能會引起軟中斷增高，那我們來看下具體怎么影響的。

tcp_v4_init_sock---->tcp_init_sock---->tcp_init_xmit_timers---->inet_csk_init_xmit_timers

void inet_csk_init_xmit_timers(struct sock *sk,
                   void (*retransmit_handler)(unsigned long),
                   void (*delack_handler)(unsigned long),
                   void (*keepalive_handler)(unsigned long))
{
    struct inet_connection_sock *icsk = inet_csk(sk);

    setup_timer(&icsk->icsk_retransmit_timer, retransmit_handler,
            (unsigned long)sk);
    setup_timer(&icsk->icsk_delack_timer, delack_handler,
            (unsigned long)sk);
    setup_timer(&sk->sk_timer, keepalive_handler, (unsigned long)sk);
    icsk->icsk_pending = icsk->icsk_ack.pending = 0;
}

我們看到，在這個地方設置了重傳定時器icsk_retransmit_timer，根據軟中斷的數組：

enum
{
    HI_SOFTIRQ=0,
    TIMER_SOFTIRQ,
    NET_TX_SOFTIRQ,
    NET_RX_SOFTIRQ,
    BLOCK_SOFTIRQ,
    BLOCK_IOPOLL_SOFTIRQ,
    TASKLET_SOFTIRQ,
    SCHED_SOFTIRQ,
    HRTIMER_SOFTIRQ, /* Unused, but kept as tools rely on the
                numbering. Sigh! */
    RCU_SOFTIRQ,    /* Preferable RCU should always be the last softirq */

    NR_SOFTIRQS
};

我們的timer，是利用TIMER_SOFTIRQ 這個中斷號，那么根據中斷號在cpu上分布是否均勻，就能看出影響多大。

 LOC: 1072490396  678867892  808702249  738663051  694968438  664162833  654867572  651600329  654034656  645216969  627279751  639649619  641258373  639135342  635356673  641374876  637985751  629441830  632710723  631181922  860372920  811835568  721220382  669551672  649964241  632893235  628735585  624749341  622625858  616301049  619922385  612601767  612468721  614664270  616217297  614498541  610157489  607806218  610633457  604827668 1012416149  991506038  804318769  713451371  635498936  622276467  613574278  604650512  596876703  594943840  589362031  598699322  591033519  592127520  590210531  600537489  590585630  585989825  589738219  589555728  801802931  800267559  706742143  638665014  607582520  588593222  582048215  571846551  576418826  574034238  578342405  567753955  576671298  570976007  573807289  573966353  568759967  891048780  570053521  571002170   Local timer interrupts

除了cpu0，其他核都是很均勻了。

事實上，這個問題直接分析/proc/interrupts就能看出來，其實是由於某些核上的NET_TX_SOFTIRQ非常少導致的。

那么問題來了，雖然我們知道了重傳的報文對cpu的軟中斷數不均衡情況影響很小，那為什么呼叫的時候，各個cpu的軟中斷數相差很大呢。

回到問題的本質，我們的系統其實開啟了RPS和RFS，

#  cat /sys/class/net/eth10/queues/rx-0/rps_cpus
00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000ffff,ffffffff,ffffffff

# cat /sys/class/net/eth10/queues/rx-0/rps_flow_cnt
4096

 

RPS（Receive Packet Steering）主要是把軟中斷的負載均衡到各個cpu，簡單來說，是網卡驅動對每個流生成一個hash標識，這個HASH值得計算可以通過四元組來計算（SIP，SPORT，DIP，DPORT）。看起來好像沒問題,

其實問題就在於，我們是多媒體服務器，用於測試的機器的ip並沒有篡改，我們的源ip和目的ip都是固定的，目的端口在第一次請求建聯的時候也是固定的，后續的發流也就是靠源端口和目的端口來保證hash的散列性，通過抓包發現，其實這個散列性並不好。當我們把源ip配置很多的時候，現象得到了很大的改善，把服務器的目的ip多增加一些的時候，效果也更好。

 

進一步地，除了用肉眼觀察，我怎么確定我們的軟中斷處理情況呢？答案是perf。

比如我要查看cpu14的軟中斷處理情況，

[root@host]# perf top -C 14 -e  irq:softirq_entry

Samples: 290K of event 'irq:softirq_entry', Event count (approx.): 238847                                                                                                                                 
Overhead  Trace output                                                                                                                                                                                    
  92.30%  vec=3 [action=NET_RX]
   3.24%  vec=0 [action=HI]
   2.83%  vec=1 [action=TIMER]
   1.09%  vec=9 [action=RCU]
   0.49%  vec=7 [action=SCHED]
   0.05%  vec=2 [action=NET_TX]

可以明顯看出，收包是中斷的大頭，然后看哪個中斷號占其中的大頭呢？可以很明顯看到irq為1355的就占了絕大多數。

perf top -C 14 -e  irq:irq_handler_entry
 90.10%  irq=1355 name=i40e-eth7-TxRx-35
   9.06%  irq=1626 name=i40e-eth2-TxRx-35
   

 

所以說，雖然中斷綁核了，但不一定就中斷均勻，因為某個中斷號觸發次數可能就別的中斷號高很多。

這么說，如果中斷數量差不多，是不是si%就應該差不多呢，理論上是如此，理論上的意思就是：cpu處理該中斷的時間消耗差不多，因為top里面看的是時間占比，

比如同樣處理一個中斷，不同的cpu核的頻率不一樣的話，也會造成處理軟中斷最終的時間占比不一樣。這種情況比較罕見，需要使用如下命令進行確認：

# cpupower -c 0 frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1000 MHz - 2.70 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1000 MHz and 2.70 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: 2.70 GHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: yes