FreeBSD
ethernet

FreeBSDのEthernetドライバ


はじめに

MIPS系のルータのFreeBSD化をいろいろ試しているが、コンソールが使える、rootfsがマウントできてログインできる、この次にはやはりnetworkが使えるようにしたいと思いFreeBSDのEthernetドライバの事を調べてみた。ネットワークが使えないFreeBSDなんて、、、


Ethernetドライバとは

Ethernetドライバは基本的にはカーネルコードから送られてくるデータを送信し、ハードウエアから送られてくるデータをカーネルコードに引き渡す事になる。FreeBSDではifnetというフレームワークがこのカーネルコードとのデータのやり取りをサポートしている。

netdriver.png

Ethernetドライバも一般のドライバと同じように作られていてprobe,attachというコードにより処理が始まります。Ethernetドライバではattachの時にifnetへ登録をおこないます。

    ifp = sc->tulip_ifp = if_alloc(IFT_ETHER);

/* XXX: driver name/unit should be set some other way */
if_initname(ifp, "de", sc->tulip_unit);
ifp->if_softc = sc;
ifp->if_flags = IFF_BROADCAST|IFF_SIMPLEX|IFF_MULTICAST;
ifp->if_ioctl = tulip_ifioctl;
ifp->if_start = tulip_start;
ifp->if_init = tulip_init;
IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen);
ifp->if_snd.ifq_drv_maxlen = ifqmaxlen;
IFQ_SET_READY(&ifp->if_snd);

ifmedia_init(&sc->tulip_ifmedia, 0,
tulip_ifmedia_change,
tulip_ifmedia_status);

ether_ifattach(sc->tulip_ifp, sc->tulip_enaddr);

送信はカーネルから登録した関数(上のコードではtulip_start)にmbufが渡されるので、それをハードウエアに送り込みます。受信はハードウエアの割り込みやポーリングでデータが入ってきた事がわかるので、それをif_inputでカーネルに引き渡します。if_inputはLinuxでのskb_putにあたります。


Tulip

Tulipとは1990年代DECが作っていた古いPCI Ethernetチップのコードネーム(?)です。このチップのドライバコードはsys/dev/deにあります。このコードはいろいろなチップに対応するためにちょっと見通しが悪いです。おそらくi386 BSDのころからあったのかもしれません。devの下のdc,vr(VIA Rhine),wb(Winbond)もTulip互換系のようです。DECの半導体部門は1998年にIntelに買収されたため21143はIntelからもリリースされています。

Tulipの21041などのDECのpdfドキュメントはネットで入手可能です。初期の物はpsフォーマットだったりして時代を感じます。

Ethernetの話ではないですが話ですが、DECのAlpha部門は2000年代に入ってからIntelに売却されているのですが、ところがAlphaテクノロジでIA32を64Bit化されたチップがAMDから発売されたのはなんとも皮肉な話です。

どのような経緯かは定かではないのですが、TulipはSiByteやAtherosやIDTのSOCでも採用されたようです。RT1310もTulipのようです。

SOCで採用されたTulipはPCIではなくメモリマップで提供されています。

TulipのレジスタはCSRと呼ばれて、0から8までが元々の仕様で、それ以外は拡張されたものになります。Ethernetアドレスを拡張されたCSRに設定するパターンと、セットアップフレームとして送信して設定するパターンがあります。CSRのバウンダリは4バイトや8バイトだったりします。

拡張は既存のCSRの空いているビットを使ったり、CSRを増やしたりなど、CSRのチップによって様々で注意が必要です。

このチップにはdmaが入っていて送信/受信ともdmaで処理する事ができます。dmaはDescriptorという16バイトの構造により処理をおこないます。Descriptorにはステータス、コントロールとサイズ、バッファへのポインタが2つ入っています。それぞれ32bitで4バイト×4となります。

Descriptorは連続したリスト形式(Implicit Chain)か、二つ目のバッファポインタに次のDescriptorへのポインタを入れるリンク形式(Explicit Chain)で構成されます。ドライバの実装はこのどちらかを使う事になります。

tulip.png

Descriptor自体は固定で持つ事ができますが、バッファのポインターの実体のmbufは動的に指定する必要があります。

受信用のDescriptorのバッファはmbufを事前に用意しておいて、割り込みが上がってデータが入ったmbufをifに渡して、新しいmbufをDescriptorに貼付けます。

送信用のDescriptorにはifから引き渡されたmbufを貼付けて送信を開始します。この処理は大きく分けると空のリストに追加する場合と、既にリストにエントリーがあるところに追加する場合があります。空のリストに追加する場合はデータを登録してstartとendのフラグをセットします。既に登録されている場合は既存のデータのendのフラグクリアして新たにデータを追加して、endのフラグを設定します。

Kernel APIのbus_dma_tag_create() -> bus_dmamem_alloc()を呼ぶとカーネルからアクセスするためのKVAなアドレスが返ってきます。次にbus_dmamap_load()するとコールバックにdma に使用する物理アドレスが入ったbus_dma_segment_tが渡ってきますので、Tulipのレジスタ(CSR)に渡します。

送信時のDescriptorのbufferはbus_dmamap_load_mbuf_sgでmbufの物理アドレスを受け取りバッファのポインタとして利用します。

注意が必要なのはキャッシュが効いて、実メモリに書かれていないデータをdmaしてしまわない事です。このためにbus_dmamap_sync()などを適宜呼ぶ必要があります。

dma.png

送信については全てDMAされますが、受信についてはMACに設定されたアドレスに送られてきたものと、EthernetのブロードキャストとマルチキャストパケットがDMAされてドライバに渡されます。マルチキャストパケットは限定して受け取る設定ができるチップもあるようです。

通常のEthernetチップはMACとPHYという組み合わせで構成されています。PHYの設定もMACのレジスタ(CSR)でおこなう事ができます。

Ether.png

MACとPHYはMIIという仕様で接続されていている。FreeBSDでは古くはMIIは各ドライバで実装していたが3.0くらいからNetBSD由来のmiibusが持ち込まれたようだ。deなどの古いドライバはmiibusは実装されていません。

ルータなどでEthernetスイッチ機能がある場合はPHYの代わりにSwitchチップを接続しています。

dev/etherswitchでは、miiをmdioという仕組みに差し替えて、MACからの接続をmidoで代理するmiiproxyというインターフェースを利用しています。またmdioは実質的にはmiiなのですが、スイッチに付いているPHYをコントロールする機能も提供しています。


promiscuousモード

大抵のEthernetチップはpromiscuousモードという物をもっている。これは通常Ehernetチップは自分のMacアドレスのユニキャストと指定されたマルチキャスト、それとブロードキャストのEthernetパケットを時受信してホストに上げるのだが、すべてのパケットをホストに上げるモードになる。これはtcpdumpなどで利用されるモードになる。

インターフェースがこのモードになってもインターフェースの先にSwitchがついていると確認が面倒だったりする。

もし二つのインターフェースがある場合はbridgeを試す事でこのモードの動作確認が出来る。

ちなみにpromiscuousとは良くないスラングのようです。


テストケース

送信はカーネルから渡されたmbufをDMAに突っ込むだけなので、ブロードキャスト・マルチキャスト・ユニキャストの種類は関係ないのですが、受信についてはデバイスが処理するのでそれぞれのタイプの確認が必要です。


  • 内から外へping - ブロードキャスト(ARP)と1対1パケットの確認

  • 外から内へping - ブロードキャスト(ARP)と1対1パケットの確認

  • iperf3での双方向のテスト

  • 外から送信されたマルチキャストを受信

  • tcpdumpで自分以外のパケットの確認

  • などなど


参考資料

FreeBSD_kernel_networking.pdf

Lecture 23: More devices - UARTとTulipのドライバの解説があります。

FreeBSDでインタフェース名につけられる名前の根拠他

NIC MANIA - 古いですがいろいろなNICのレビューがあります。

ルータのEthernet

FreeBSDのカーネルデバッグ

FreeBSD device driver で DMA


後日談

これを調べていたのはAR2315のEthernetドライバを作ろうと思ったのが、きっかけでした。当初deのコードをコピーしてとりあえず動かしてみようと思い、試していたのですがうまくいかず一回あきらめました。で、この記事を書いた後にもう一度mips/idt/if_kr.cをベースに試したところうまく動くようになりました。if_krもTulipと同じ16バイトのDescriptorを使っていますが、構成が微妙に違っています。その辺をNetBSDのコードを参考に修正してみました。そもそもdeのコードはいろいろなサポートコードがはいって、複雑になっている上にmiibusバス導入以前のコードでした。ただAR2315を使ったターゲットはPHYではなくSWITCHが接続されているのでPHYのコードは実装せず、RedBootが初期化した状態をそのまま使うコードになっています。ターゲットにっては動かなくなるので、ほんとはよくないんですかね。

cとhファイルをコピーして"kr_"と"KR"を置換しました。krは割り込みが4つありますがAR2315は1つなので書き換えました。

AR2315ではTulip由来のCSRが0x1000からあり、0x0000からはAR2315固有の設定のCSRがあります。

元々のPCIカードのTulipはMACアドレスをボードに持っていたですが、SOCに入っているTulip互換デバイスは、MACアドレスをコードで設定するためにCSRが拡張されています。

probe,attachやバッファの管理はkrのコードベースで、CSRアクセスや割り込み処理はNetBSDのコードをコピーしました。

外からのpingはすぐに動いたのですが、中から外へのpingがすべてlossしてしまう状態でした。いろいろ調べたところ、1296行のキャッシュの処理が悪さをして、mbufのデータを壊していました。if_krってちゃんと動くのかな。。。

とはいえgonzoさんのコードは見やすくてよいです。

are_fixup_rx()でTCPヘッダーを4バイトバウンダリに合わせているのですが、元のコードはmbufの全体をコピーしていましたが、packetのサイズだけコピーするようにしています。あとm_adjは8バイトの必要なく4バイトで十分なので変更してあります。このことはfreebsd-mipsのmlにも報告してあります。

mbuf_dma.png

上の図ではm_getclで2Kの受信用のバッファを用意してm_adjで先頭に4バイトの空きを作りDescriptorに登録します。DMAでパケットをメモリにコピーされたら、2バイト前にcopyしてTCPヘッダーを4バイトアライメントに合わせます。

https://github.com/yamori813/freebsd/blob/zrouter/sys/mips/atheros/ar531x/if_are.c

当初うまくいかなかった原因として、Endianに関する設定がAHBに一つとデバイス側に三つあり混乱してしまった事があります。AHBで変換してデバイスでも変換すると元に戻ってしまいます。^ ^;

RT1310のドライバも作ってみたのだが、AR2315ではCSRで自己のMACアドレスを設定していたが、RT1310ではsetup frameを使っていたのでdev/dcを参考に実装してみた。あと違いはエンディアンと、CSRが4バイトではなく8バイトバウンダリくらいだった。

と思ったのだが、実はすぐに落ちる状態であった。確認したところencap()のEFBIGでpanicしているようだったので、この部分の処理を他のコードからコピーしたところとりあえず落ちなくはなった。まだ20世紀の頃、鮎川誠がJSを使っているって話を聞かれて、「良さそうなページからコピーしている、ロックの基本はコピーです。」というような話をしていたな。

テストしてみようと思い、ネットで探したところiperf3というオープンソースがあり、ZRouterのtargetにつっこんでイメージを焼いてみた確認してみた。

テストしてみるとすぐにネットワークが落ちてしまう。。。ARの方は正常に動作します。

でいろいろ試してみて、encapの前半の処理をvrからコピーしてみたところ、EFBIGのエラーは出なくなったのだが、まだ落ちる。

モリモリデバッグライトを入れて、調べたところTxのDMAでUnderflow Errorが起きているようだ。どうもDMAのディスクリプタのOwn,Start,Endのフラグがまずいようだったので、ごにょごにょしたら、うまく動くようになった。継ぎ足しのときにEndフラグを引っこ抜いて、Startを付けないようにしました。

このようにある程度のレジスタ互換はあってもDMAの挙動はチップ毎に微妙に違っているようです。

とりあえずこれで落ちたりしなくはなりましたが、いろいろいじっている間にiperf3でRオプションで時々データが流れなくなっていましたが、とりあえず動いているのでそのうちデバッグしたいと思います。

久しぶりにちょっといじってみてbridgeを試してみたのだが、bridgeで必要なpromiscuousモードの実装が抜けていたので、追加してみた。

これでとりあえず動くようになったのだが、負荷をかけると落ちる状態で調べてみた。問題は二つあって、bridgeしなくなる問題と受信パケットが壊れる問題であった。

bridgeしなくなる問題は、初期化のパラメータ(IFQ_SET_MAXLENとif_snd.ifq_maxlen)に問題があった。

パケットが壊れる問題はなぜか負荷をかけると、受信データが4バイト連ずれてバッファにDMAされている。。。なぜかすべてではないのだが、CRCエラーも発生している。

iperf3で調べてみると、Switchの方につながれたfv0では問題が起きるが、Phy相当とつながっているfv1では問題が起きません。これからfvの問題ではなくSwitchの問題である事が特定できました。このターゲットはip175cが使われていてetherswitchのドライバを利用しています。ためしにmidoのphyアドレス29以降の書き込みを無効にしたところ問題が起きなくなりました。dev/etherswitch/ip17x/ip175c.cの設定が原因のようです。

実装されているSwitchチップはIP175CなのだがIP175C/IP175CH enable register(29:31)が0x175aになっていて、ここに0x175cを書き込むとダメになるようだ。このターゲットは2ポートEtherでVLANの必要もないので、このターゲットでのetherswitchの利用はあきらめる事にした。

iperf3での確認

SOC
TYPE
IF
normal
revers

AR5312
MIPS 4K
are
17.7/17.7 Mbits/sec
11.6/11.5 Mbits/sec

AR2313
MIPS 4K
are
30.6/30.6 Mbits/sec
27.1/27.1 Mbits/sec

AR5315
MIPS 4K
are
18.2/18.2 Mbits/sec
16.3/16.2 Mbits/sec

AR2317
MIPS 4K
are
16.3/16.3 Mbits/sec
15.0/14.9 Mbits/sec

AR2318
MIPS 4K
are
18.1/18.1 Mbits/sec
16.4/16.4 Mbits/sec

RT2880
MIPS 4K
rt
9.29/9.16 Mbits/sec
9.50/9.50 Mbits/sec

RT2880+RTL8366SR
MIPS 4K
rt
8.49/8.43 Mbits/sec
35.0/34.9 Mbits/sec

RT3050
MIPS 24K
rt
16.6/16.5 Mbits/sec
74.3/74.2 Mbits/sec

MT7620
MIPS 24K
rt
70.4/70.4 Mbits/sec
88.8/88.8 Mbits/sec

AR7240
MIPS 24K
arge
45.9/45.8 Mbits/sec
87.9/87.8 Mbits/sec

AR9132
MIPS 24K
arge
117/117 Mbits/sec
125/125 Mbits/sec

AR9341
MIPS 74K
arge
58.9/58.8 Mbits/sec
91.6/91.6 Mbits/sec

RT1310
ARM V5T
fv
13.7/13.7 Mbits/sec
42.7/42.5 Mbits/sec

対向はMicroserverでGigaのスイッチを挟んで同じ環境で確認しています。

fv/areも最初そうでしたが、iperf3で落ちるドライバもたまにあります。上記のようにスイッチが落ちるケースものあるので、ドライバの問題とも言い切れないのですが。

2018/10 古いドライバを消すって話が出てます。

https://github.com/freebsd/fcp/blob/master/fcp-0101.md


mgeについて

MarvellのSOCで使われているmgeを調べてみました。

RXのディスクリプタはlongが4つです。

スクリーンショット(2019-02-05 17.26.54).png

これを16バイトアラインで並べるのですが、リングを作るときにこんなふうにしてました。

        desc_paddr = 0;

for (i = size - 1; i >= 0; i--) {
省略
/* Chain descriptors */
dw->mge_desc->next_desc = desc_paddr;
desc_paddr = dw->mge_desc_paddr;
}
tab[size - 1].mge_desc->next_desc = desc_paddr;

下から作って最後に下と上を引っ付けるってコードです。一瞬理解できなかったのですが、あまり分かりやすいコードではないですね。