在多核系統(tǒng)上網(wǎng)絡(luò)數(shù)據(jù)轉(zhuǎn)發(fā)實驗和一點(diǎn)思考

platinum

原帖由 思一克 于 2009-5-20 12:39 發(fā)表


基于連接的亂序就沒有了。一個連接給一個CPU, 就基本沒有后面的先到問題了（有一點(diǎn)是正常的，比如因為路由過程中的狀況）。
基于包不管連接，那問題是相當(dāng)嚴(yán)重。我實驗過的。

那么也就是說，如果是 IP 協(xié)議，簡單根據(jù) SIP/DIP，如果傳輸層是 TCP/UDP，那么再加上 SPORT/DPORT 的方式算出 hash 值，% 給 CPU_NUM
這樣雖然做不到完美均衡，但在連接數(shù)多的環(huán)境中還是會相當(dāng)有用的了！至少比什么都不做強(qiáng)得多

思一克

原帖由 platinum 于 2009-5-20 13:00 發(fā)表

那么也就是說，如果是 IP 協(xié)議，簡單根據(jù) SIP/DIP，如果傳輸層是 TCP/UDP，那么再加上 SPORT/DPORT 的方式算出 hash 值，% 給 CPU_NUM
這樣雖然做不到完美均衡，但在連接數(shù)多的環(huán)境中還是會相當(dāng)有用的了！至 ...

是的。不用完美。能避免絕大部份就可以了。
我做的那個網(wǎng)絡(luò)軟中斷CPU并行就是你說的意思。

Solaris12

原帖由 terryfe 于 2009-5-20 10:17 發(fā)表
做了好久的SMP環(huán)境下的包轉(zhuǎn)發(fā)，總結(jié)幾點(diǎn)：
1. 對于普通網(wǎng)卡Linux協(xié)議棧無法進(jìn)行實質(zhì)上的多CPU負(fù)載均衡，需要支持RSS（多隊列）的網(wǎng)卡，千兆比如intel 82575/6，萬兆如intel 82598等。網(wǎng)卡對數(shù)據(jù)流進(jìn)行hash然后分配到多個隊列上，每個隊列對應(yīng)一個msi-x中斷vector。這樣就真正實現(xiàn)了多CPU同時處理協(xié)議棧。
2. linux內(nèi)核從2.6.23開始支持多隊列的網(wǎng)卡，到2.6.27才完整支持（仍需要hack達(dá)到性能最優(yōu)），主要是NAPI結(jié)構(gòu)的修改和Qdisc的多隊列化。這種情況下在nehalem之前的平臺上，萬兆網(wǎng)卡測試轉(zhuǎn)發(fā)時FSB成為瓶頸（多CPU爭用）。
3. Nehalem可以解決FSB的問題，萬兆多隊列卡轉(zhuǎn)發(fā)可以做到500萬pps，此時PCIE的pps成為瓶頸。
4. 繼續(xù)上升可能需要PCIE v2.0 的支持，或者像某些NP架構(gòu)中使用專用總線避開PCIE的瓶頸。
...

這是一種硬件方案。


軟件上可以模擬這個方案，把RSS這種東西在協(xié)議棧級別實現(xiàn)，Solaris叫fanout, 基于連接來負(fù)載均衡。

[ 本帖最后由 Solaris12 于 2009-5-20 13:33 編輯 ]

eexplorer

原帖由 思一克 于 2009-5-20 13:08 發(fā)表


是的。不用完美。能避免絕大部份就可以了。
我做的那個網(wǎng)絡(luò)軟中斷CPU并行就是你說的意思。

最近google提交了類似的patch，原理差不多

http://marc.info/?t=124140985500002&r=1&w=4

ShadowStar

原帖由 Solaris12 于 2009-5-20 13:30 發(fā)表



這是一種硬件方案。


軟件上可以模擬這個方案，把RSS這種東西在協(xié)議棧級別實現(xiàn)，Solaris叫fanout, 基于連接來負(fù)載均衡。

其實，我覺得軟RSS的實現(xiàn)，在超過2個CPU核心以上才有意義。
或者說，這種均衡在CPU核心數(shù)量越多的情況下越有利。

不清楚Solaris上是否有類似Linux的netfilter conntrack來處理網(wǎng)絡(luò)連接？

如果有的話，fanout和連接跟蹤是否有結(jié)合呢？

wheel

/etc/sysctl.conf  改了后速度快了不少


# Controls IP packet forwarding
net.ipv4.ip_forward = 1
net.ipv4.tcp_fin_timeout=9
net.ipv4.tcp_max_tw_buckets =300
net.ipv4.tcp_tw_recycle=1

#VMfs

vm.drop_caches=3
vm.swappiness =100
vm.lowmem_reserve_ratio=16 16 4
vm.vfs_cache_pressure=163

#nfs
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.rmem_max=262144
net.core.wmem_max=262144
net.ipv4.udp_mem = 8388608 12582912 16777216
net.ipv4.udp_rmem_min=65536
net.ipv4.udp_wmem_min=65536
net.ipv4.tcp_window_scaling=1
net.ipv4.ip_local_port_range=1024 65535

terryfe

原帖由 ShadowStar 于 2009-5-20 16:33 發(fā)表


其實，我覺得軟RSS的實現(xiàn)，在超過2個CPU核心以上才有意義。
或者說，這種均衡在CPU核心數(shù)量越多的情況下越有利。

不清楚Solaris上是否有類似Linux的netfilter conntrack來處理網(wǎng)絡(luò)連接？

如果有的話 ...

fanout機(jī)制確實是想多利用sparc的CMT技術(shù)，但是目前還是受制于PCIE總線的限制，至少我用ixgbe的硬件hash在opensolaris上只能做到160wpps（進(jìn)行了大量hask....）。
NIU那塊走專用總線的卡應(yīng)該可以解決該問題，但是現(xiàn)在的內(nèi)核協(xié)議棧支持好像還差不少....

軟件實現(xiàn)的問題可能在于用于分發(fā)的CPU很可能成為瓶頸，因為同時只能有一個CPU來做這件事情，sparc的主頻低啊== .....
不過一直沒時間去試solaris在x86上軟RSS實現(xiàn)的表現(xiàn)，不過想做到單機(jī)萬兆線速只能上硬件了..

估計未來的nehalem架構(gòu)+PCIE2.0的萬兆RSS網(wǎng)卡可以接近極限

Solaris12

原帖由 terryfe 于 2009-5-20 17:13 發(fā)表
fanout機(jī)制確實是想多利用sparc的CMT技術(shù)，但是目前還是受制于PCIE總線的限制，至少我用ixgbe的硬件hash在opensolaris上只能做到160wpps（進(jìn)行了大量hask....）。
NIU那塊走專用總線的卡應(yīng)該可以解決該問題，但是現(xiàn)在的內(nèi)核協(xié)議棧支持好像還差不少....

軟件實現(xiàn)的問題可能在于用于分發(fā)的CPU很可能成為瓶頸，因為同時只能有一個CPU來做這件事情，sparc的主頻低啊== .....
不過一直沒時間去試solaris在x86上軟RSS實現(xiàn)的表現(xiàn)，不過想做到單機(jī)萬兆線速只能上硬件了..
...

NIU + Crossbow的bug還很多呢。

如果是single ring的話， fanout的確是一個CPU做，但多個隊列的時候，如果用pcitool把中斷放到不同的core，理論上每個接收中斷上來的CPU都可以做吧。

terryfe

原帖由 Solaris12 于 2009-5-20 17:38 發(fā)表


NIU + Crossbow的bug還很多呢。

如果是single ring的話， fanout的確是一個CPU做，但多個隊列的時候，如果用pcitool把中斷放到不同的core，理論上每個接收中斷上來的CPU都可以做吧。

前提就是硬件的多隊列嘛。所以軟RSS的實現(xiàn)在高壓力下治標(biāo)不治本啊...

思一克

現(xiàn)在有多隊列網(wǎng)卡了。一個隊列給一個CPU就可以。效果應(yīng)該不錯的。