[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

statistics of TX mbuf size and chains



筒井です。

なんとなく sgimips の O2 の内蔵イーサネットのドライバの
送信部分をいろいろといじっているのですが、各ドライバの
(*ifp->if_start)() に渡される送信パケットについて、
以下のような統計的データってどこかにないでしょうか?

・送信パケットのサイズ
・ヘッダ部分のサイズ、フラグメント数、alignment状態
・データ部分のサイズ、フラグメント数、alignment状態

当然ながらそのマシンがどのような状況で使われているかで
変わってくるとは思いますが、どんな例でもいいので
具体的な値はどこかにないでしょうか。

パケットサイズだけならば
http://bmilekic.unixdaemons.com/netbuf_bmilekic.pdf
に一例があったのですが、パケット内部の chain については
ぱっと検索したところではすぐに出てこないようです。


O2 の内蔵イーサネットの mec(4) のチップは、各送信パケットに対して
(a) 1〜120バイトの固定バッファ
(b) 8 byte aligned かつ連続なバッファを指定するディスクリプタ×3
を指定できるようになっています。
が、今のコードだとほとんどのパケットが(b)をそのまま使えず、
送信 DMA用に新しい mbuf を確保し直してコピーしています。

これを、パケット中でフラグメントしていて unaligned
になっているのはほとんどがヘッダ部分で、
データ部分はほぼそれなりの境界に位置してかつ連続している
と仮定して、

(1) もともと 120バイトより小さいパケットはすべて (a)にコピーする
    120バイトより大きいパケットについては、
(2) 先頭から約90バイトまでに含まれるフラグメントは (a)にコピーする
(3) 残り部分の先頭が 8byte 境界になければ端数を (a)にさらにコピーする
(4) 残りの部分が (b)の 3つの領域に収まればそれをそのまま指定する
(5) 収まっていなければあきらめて新しい mbuf を確保してコピー

というコードをごちゃごちゃと書いてみました。

それで適当に NFS mount や cvs update 等々をさせながら evcnt(9) で
統計を取ってみたのですが、本当に意図通り動いているのか、
そもそもテスト環境としてどうするのが適切なのか、
どうにもわからなくなったもので……。

---
Izumi Tsutsui