TC アタッチするとき skb の大きさいじれないかなあ（そもそも一部分だけ舐められるように指定する、など）

sk_buff の読み方、おかしいかも。__sk_buff.len() は buf の長さであってパケットの長さではなさそう？

iperf3 は Retr を setsockopt で見ていた

bridge interface は gro, tso などを切っても MTU 65536 でパケットをまとめてくる
Docker は内部で netns 切ってた気がするから、そこにアタッチされた veth で tso 切ればいいんではないか
container 内部から切れない

https://qiita.com/sugimount/items/5c92c4976f9949650403
ip a で veth name 得て
ethtool -
netns をもってきて veth の tso を切れば本来のパケット単位で TC classifier を動かすことができたが、今度は userspace 側から読む部分で律速していそう

SimpleAnalyzer は eBPF 側でどのようにペイロード読ませてもいい感じに読めてしまっている。eBPF 側では ctx.len() だけパケットを読まないとやはりダメっぽい（TLS 1.2 の復号がしくるようになった）。つまり、現状の実装はちゃんとしている。

結局のところ、転送の箇所で律速するという結論になりそう。並列性を高めたときも同様。実は、暗号通信の復号自体にはそこまで大きなレイテンシは関わってこない。
up_rx, up_tx は消し去ることが可能で、さらに



eBPF memory usage
$ sudo bpftool map show
528: ringbuf  name UNKNOWN_PACKETS  flags 0x0
        key 0B  value 0B  max_entries 1048576  memlock 1065304B
        pids ebpf-afw-tui(90261)
531: hash  name V4_RULE_MAP  flags 0x0
        key 16B  value 4B  max_entries 1024  memlock 91840B
        pids ebpf-afw-tui(90261)

$ sudo bpftool prog show
683: sched_cls  name ebpf_afw_in  tag 5558b060b5fa3c5a  gpl run_time_ns 1046607047 run_cnt 808320
        loaded_at 2024-01-26T19:13:42+0900  uid 0
        xlated 7384B  jited 4216B  memlock 8192B  map_ids 531,528,529,532,527
        pids ebpf-afw-tui(90261)
684: sched_cls  name ebpf_afw_e  tag aba97564b994c0a9  gpl run_time_ns 94870145 run_cnt 45373
        loaded_at 2024-01-26T19:13:42+0900  uid 0
        xlated 7384B  jited 4222B  memlock 8192B  map_ids 531,528,529,532,527
        pids ebpf-afw-tui(90261)




最終

iperf3
  • Host, 1 CPU (virtually)
    • 930 Mbps
    • 45 %
  • Host, 1 CPU
    • ? Mbps
    • ? %
  • Host, 8 CPUs
    • 930 Mbps
    • NaN %
  • Allowed, 1 CPU (virtually)
    • 930 Mbps
    • 55 %
  • Allowed, 1 CPU
    • ? Mbps
    • ? %
  • Allowed, 8 CPUs
    • 930 Mbps
    • NaN %
  • Transfer, 1 CPU (virtually)
    • 718 Mbps
    • 100 %
  • Transfer, 1 CPU
    • ? Mbps
    • ? %
  • Transfer, 8 CPUs
    • 931 Mbps
    • NaN %
  • Analyzed, 1 CPU (virtually)
    • 663 Mbps
    • 100 %
  • Analyzed, 1 CPU
    • ? Mbps
    • ? %
  • Analyzed, 8 CPUs
    • 931 Mbps
    • NaN %


ping
  • Host, 8 CPUs
    • rtt min/avg/max/mdev = 0.230/0.269/0.307/0.019 ms
  • Allowed, 8 CPUs
    • rtt min/avg/max/mdev = 0.304/0.352/0.378/0.018 ms
  • Transfer, 8 CPUs
    • rtt min/avg/max/mdev = 0.309/0.376/0.409/0.024 ms
  • Analyzed, 8 CPUs
    • rtt min/avg/max/mdev = 0.320/0.376/0.420/0.023 ms


 
browser https://www.softlab.cs.tsukuba.ac.jp/alumni.html
  • Host, 8 CPUs
    • 0.59 seconds
  • Allowed, 8 CPUs
    • 0.74 seconds
  • Transfer, 8 CPUs
    • 1.43 seconds
  • Analyzed, 8 CPUs
    • 1.44 seconds




Outdated

As of https://git.softlab.cs.tsukuba.ac.jp/ichiki/ebpf-afw-rust/commit/55095566341fdf11c3a544a24dbcbe704eb8e924 の記録。並列性が足りていない + 無駄な MPSC チャネルがあるためパフォーマンスが低い

iperf3
  • Host, 1 CPU (virtually)
    • 930 Mbps
    • 45 %
  • Host, 1 CPU
    • 930 Mbps
    • 10 %
  • Host, 8 CPUs
    • 930 Mbps
    • NaN %
  • Allowed, 1 CPU (virtually)
    • 930 Mbps
    • 55 %
  • Allowed, 1 CPU
    • 930 Mbps
    • 66 %
  • Allowed, 8 CPUs
    • 930 Mbps
    • NaN %
  • Transfer, 1 CPU (virtually)
    • 193 Mbps
    • 100 %
  • Transfer, 1 CPU
    • 180 Mbps
    • 100 %
  • Transfer, 8 CPUs
    • 225 Mbps
    • NaN %
  • Analyzed, 1 CPU (virtually)
    • 108 Mbps
    • 100 %
  • Analyzed, 1 CPU
    • 84 Mbps
    • 100 %
  • Analyzed, 8 CPUs
    • 217 Mbps
    • NaN %


ping
  • Host, 8 CPUs
    • rtt min/avg/max/mdev = 0.230/0.269/0.307/0.019 ms
  • Allowed, 8 CPUs
    • rtt min/avg/max/mdev = 0.316/0.374/0.429/0.029 ms
  • Transfer, 8 CPUs
    • rtt min/avg/max/mdev = 0.326/0.366/0.398/0.021 ms
  • Analyzed, 8 CPUs
    • rtt min/avg/max/mdev = 0.315/0.382/0.420/0.030 ms

 
browser https://www.softlab.cs.tsukuba.ac.jp/alumni.html
  • Host, 8 CPUs
    • 0.59 seconds
  • Allowed, 8 CPUs
    • 0.74 seconds
  • Transfer, 8 CPUs
    • 1.43 seconds
  • Analyzed, 8 CPUs
    • 1.44 seconds