このページの翻訳:
ソースの表示
最近の変更サイトマップ

FreeBSDのif_bridgeが5倍速くなるらしい

FreeBSDのネットワークブリッジ機能、if_bridge(4)が遅いってのは以前書いたとおりなのだけど、今後、おおむね5倍に高速化される見込みらしい。

FreeBSD Foundationの記事によれば、現状のif_bridgeは、重いBRIDGE_LOCK mutexのせいで、CPUのコア数によらずスループットは最大3.7Mpps程度に制限される。この度、Kristof ProvostがFreeBSD 13-CURRENT上でロックフリーのepoch(9)を使った実装にしたところ、概ね18.6Mppsのパケットフォワードが行え、5倍の改善となったとのこと。

これはなかなかムネアツ。

一方で、現状の実装でも3.7Mpps出るってことは、最大フレームなら理屈上41Gbpsの帯域を有するハズ。にもかかわらず、iperfの実測で3.5Gbpsほどに止まるのは何でだろーなー。全二重通信で帯域が分割される点を考慮しても低すぎのような気が。

参考サイト

FreeBSDのL2ブリッジ(if_bridge)は本当に遅かった

FreeBSDでL2ブリッジを有効にするとネットワーク性能が激烈に落ちるという話がある。なんでも、ブリッジの実装であるif_bridge(4)に存在するたくさんの最適化されてないロックのせいで性能劣化を引き起こしてるとか。

いやいや、いくら何でもそんなに変わらんやろ?と思い、ブリッジの有無でiperfしてみたら、ブリッジ有りの方でありえないほど遅くなって草も生えないんですが。

測定環境は下表の通り。ネットワークまわりのチューニングとかは特にしてない。

サーバ クライアント
OS FreeBSD 12.0-RELEASE-p4 amd64 Windows 10 Pro 1903 x64
CPU Xeon E5-2648Lv3 Ryzen 1700
NIC ConnectX-3 Pro EN (L2SW経由で40Gb接続)
ソフト iperf 2.0.13 iperf 2.0.14a

ご覧の通り、現状のif_bridgeは1GbEには十分だけど、10GbE以上の環境では完全ボトルネックとなってしまう。bhyve使うときに割と困るぞこれ…。

参考サイト

世界最安の40GbE対応スイッチCRS326-24S+2Q+RMがやってきた!

真っ当な流通ルートで購入できるものでは世界最安1)と思われる40GbE対応スイッチ、CRS326-24S+2Q+RMがやってきた!流石は俺たちのMikroTik!!とかいいつつ、同社の製品を買うのは初めてだったりする。

このページに辿り着くくらいの人には釈迦に説法だろうけど、CRS326-24S+2Q+RMは10ギガビット対応のSFP+ポートを24個、加えて40ギガビット対応のQSFP+ポートを2つ備えながら499ドルという超破格を実現した頭おかしいスイッチである。普通に考えたら499ドルは結構な額だが、この性能でこの額は本当に価格破壊もいいところ。しかもEuroDKでは384ドルで売ってる()。マジでありえん。

というわけで誘惑に勝てずに買ってしまった。8/22(木)に注文して26(月)に配達される40GbE顔負けの高速配送っぷりだったけど、結局受け取りは週末までお預け。送料やら消費税やらで、最終的に448ドル+1900円となった。

設置場所の問題やらMPOケーブル不足やらで本格的には試せてないが、ひとまず下表環境のiperf3 (MTU=1500)で28Gbpsほど出ることは確認。

サーバ クライアント
OS FreeBSD 11.2-RELEASE (x64) Windows 10 Pro. (x64)
M/B Supermicro X10DRi MSI X370 SLI PLUS
CPU Xeon E5-2648L v3 @1.8GHz Ryzen 7 1700 @3.0GHz
RAM Registered DDR4-2400 16GB×4 (2133MHz駆動) DDR4-2666 16GB×4
NIC ConnectX-3 Pro EN (PCIe 3.0x8)

使われてるスイッチチップは98DX8332っぽい。明言はされてないけど、2.5GbE/5GbEにも対応してる予感…?ポートの速度設定画面にチェックボックスがあるんですけど……。

OSはRouterOSとSwOSのデュアル対応なので、一応L3の処理も可能。だけどスイッチチップで処理できないものはCPU処理となるうえ、内部リンクは1Gbpsなので折角の性能が死ぬ。なので素直にL2スイッチとして使うか、軽めのフィルタでWANを受けるとかに留めるのが吉。幸い10Gポートは腐るほどあるからLAG組んでL3処理は上位ルータに投げてしまえばいいかと。AT-x510-28GTXも泣いて喜ぶね!

ざっくり消費電力は以下の通り。

状況 消費電力
待機(SFPモジュールは一切挿してない状態) 13W
待機(40GBASE-SR4×2でリンクアップ) 15~16W
40GBASE-SR4でiperf実行 17W

出荷時のRouterOSバージョンではファンが結構うるさいが、6.45.5に更新したらかなり静かになった。基本は停止、内部温度に応じて回転数可変のなかなかアグレッシブな制御をしてくれるようになる。消費電力とあわせて一般のご家庭にも大変やさしい仕様と言える。ありがとうMikroTik。なお、回転時はそれなりに音がする。風切り音よりファン自体の回転音が大きい感じ。個人的には許容範囲内だけど気になる人は気になると思われる。

1)
2019年9月4日現在

FreeBSDでQSFP+トランシーバの相性によって40GBASE-SR4が再リンクしなくなる事があるっぽい

家鯖(FreeBSD 11)とメインマシン(Windows 10)をConnectX-3の40GBASE-SR4で繋ぐようになって早5ヵ月。メインマシンをスリープ&レジュームすると、40GBASE-SR4が再リンクアップせず、サーバ側のQSFP+トランシーバを抜き差しすると直る、という現象が発生することがあった。

その時は決まって、サーバ側のTXシグナルが出ていないという状況。

$ ifconfig -v mlxen0
mlxen0: flags=8947<UP,BROADCAST,DEBUG,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=ad00b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6>
        ether e4:1d:2d:74:16:e0
        hwaddr e4:1d:2d:74:16:e0
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet 40Gbase-CR4 <full-duplex> (autoselect)
        status: no carrier
        plugged: QSFP+ 40GBASE-SR4 (MPO Parallel Optic)
        vendor: Mellanox PN: MC2210411-SR4 SN: MEQSRIC0115 DATE: 2015-03-23
        compliance level: Unspecified
        nominal bitrate: 10300 Mbps
        module temperature: 40.00 C voltage: 3.22 Volts
        lane 1: RX: 0.57 mW (-2.37 dBm) TX: 0.36 mW (-4.38 dBm)
        lane 2: RX: 1.06 mW (0.26 dBm) TX: 0.37 mW (-4.30 dBm)
        lane 3: RX: 0.96 mW (-0.17 dBm) TX: 0.00 mW (-30.46 dBm)
        lane 4: RX: 1.12 mW (0.52 dBm) TX: 0.37 mW (-4.20 dBm)

スリープ&レジュームで電気的に不連続状態になるメインマシン側がそうなるならまだしも、無関係なサーバ側がなんで死ぬのか全く意味がわからないのだが、結局のところQSFP+モジュールとNICとドライバの相性らしい。とりあえず10GtekのMellanox互換モジュールAMQ10-SR4-M1からAvago AFBR-79EQPZに変えて2ヵ月ほど経つが、今のところ再現はしていない。メインマシンの方は変わらずAMQ10-SR4-M1を使っていて特に問題なし。

やっぱりサーバ側の相性ということでFAで、直ったっぽい?

逸般の誤家庭で40GbEはじめますた その3(構築編)

機材が揃ったので、サーバ/クライアント直結40GBASE-SR4ネットワークを構築する。

ネットワーク概略図を示す。

(2020-03-07 追記)

FreeBSDのL2ブリッジif_bridgeはジャイアントロックを使った実装が原因でボトルネックとなるようだ。実際、うちの環境ではブリッジなしでは30Gbpsを超えるのに対し、ブリッジを使うと12~13Gbpsで頭打ちとなる。

クライアントとサーバを40GBASE-SR4で直結し、サーバで40GbEと1GbEをブリッジする。こうすることで、40GbE対応スイッチがなくとも、40GbEによる高速化の恩恵を受けつつ既存の1000BASE-Tネットワークとの相互運用が実現できる。サーバが落ちてると、当然ながらクライアントのネットワークが使えなくなってしまうが、うちでは常時稼働させてるので殆ど問題ない。いざって時はクライアントを従来通り1000BASE-Tで繋げばいいだけだし、そこは割り切る。

40GbEといっても、ネットワークカードは何の変哲もないPCI-Expressカードだ。ビデオカード等を取り付ける要領でマシンにNICを挿し、ドライバをインストールすれば普通のNICとして使える。

FreeBSD(サーバ)では/boot/loader.confに以下の1行を追加し再起動すると、mlxen0/mlxen1というネットワークデバイスが生えてくる。

mlx4en_load="YES"

40GbEと1GbEのブリッジは/etc/rc.confに以下の設定を追加する。このサーバではsshやSambaなどのサービスを提供しているので、igb0のIPアドレスをbridge0に付け替える。ブリッジにIPアドレスを振る場合は、必ずブリッジそのもの(ここではbridge0)に対して行う。ブリッジメンバ(ここではigb0)に振ると、一見動いているように見えてブロードキャストは到達するのにユニキャストは到達しない、といった非常に分かりにくい問題を誘発することになる。

cloned_interfaces="bridge0"
ifconfig_bridge0="ether XX:YY:ZZ:00:00:01 addm igb0 addm mlxen0 up"
ifconfig_bridge0_alias0="inet 192.168.0.1 netmask 255.255.255.0"
ifconfig_igb0="up"
ifconfig_mlxen0="up"

うまくブリッジが出来上がればifconfigが↓こんな感じになる。bhyve用のブリッジも兼用してるので余計なtapが刺さってるのは無視してくだしあ。

$ ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        description: vm-public
        ether XX:YY:ZZ:00:00:01
        inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
        nd6 options=9<PERFORMNUD,IFDISABLED>
        groups: bridge vm-switch viid-4c918@
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: tap1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 8 priority 128 path cost 2000000
        member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 7 priority 128 path cost 2000000
        member: mlxen0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 4 priority 128 path cost 500
        member: igb0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 1 priority 128 path cost 2000000

クライアントのネットワークが正しく使えることを確認する。インターネットに繋いだり、サーバにsshしたり…。設定に間違いがなければ、従来と全く同じように使えるはず。

最後にSambaでファイルコピーを行ったGIF動画を貼っておく。サーバのSSD(Intel DC S3500シリーズ)の速度がボトルネックとなり10Gb/秒にも満たないが、素敵な速さだ。

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0