どうもみむらです。
最近梅雨に入ったのか夏に入ったのか、色々パッとしなくて困る日々が続いております。
先日 Windows Server 2019 (もしくは Hyper-V Server 2019) を Jumbo Frame 環境下で用いると、通信が遅くなるということが分かりましたのでメモがてら。
同じような問題に遭遇した方の一助のとなればありがたいです。
事象：
Windows Server 2019 上の Hyper-V に展開された VM において
RSC (Receive Side Coalescing, Linux では Large Receive Offload で知られている) が有効
かつ VM が Jumbo Frame の環境において、VMから見て受信方向の通信が遅くなる。
注１：Windows Server 2019 では RSC は既定で有効になっています。
注２：MTU が 2850 bytes を上回る ( >2850 ) 場合に速度低下が発生するようです。
原因：
VMSwitch において Reassemble されたパケットが VMに届かなくなる。
回避方法：
RSC を無効にするか MTU を 1500 にする
方法１：ゲスト VM の MTU を 1500 にする。
例） ip l set mtu 1500 dev eth0
方法２：ホスト側でRSC 機能を VMSwitch 単位で無効にする
例）Set-VMSwitch (Switch名) -EnableSoftwareRsc $false
方法３：ゲストVM において ethtool 等を用いて “large-receive-offload” を off にする
Linux） ethtool -K eth0 large-receive-offload off
Windows） Set-NetAdapterAdvancedProperty “*” -DisplayName “Recv Segment Coalescing” -RegistryValue 0
パケットの気持ちになってみる
最近パケットの気持ちになる、が一部界隈で有名ですので「なってみよう」と思います。
ざっくりと構成は下記の通り。
Hyper-V サーバ内に立てられた VM-01 との通信について Hyper-V サーバの前段のミラー (CAP-01) と VMSwitch のミラー (CAP-02) で通信をキャプチャして挙動を確認しよう、という構成になっています。
（なお、各キャプチャは同タイミングでのものではありません。ご了承ください）
VM-01 での curl での速度比較
事象を確認するためにまずは curl で適当な通信を発生させて速度を見てみます。
MTU 1500 の場合は Average Speed が 10.7M となっているのに対し
MTU 9000 の場合は Average Speed が 44024 となっています。
MTU 9000 の時の VM-01 のキャプチャ
上記のようになります。
No. 12 において Seq=141, Ack=1409 をサーバに対して返答していますが
その次にやってきたパケット (No.13) は Seq=16897 になっています。
（通常は直前の Ack と同じ番号の Seq が返ってきます）
そのため No.14 において Ack=1409 を再度送信され、
サーバ側からは No.16 において Seq=1409 の返答（再送）が起きてしまっています。
MTU9000 の時の CAP-02 のキャプチャ
上記のようになります。
No. 13 までは先ほどの VM-01 と同じような流れになっています。
ですが No.14 付近から 1474 bytes ではないパケットが流れはじめます。
またそれを境にして、 Ack と Seq の関係が壊れはじめるのも確認が出来ます。
たとえば No.14 は Seq=1409 として 2882 bytes の通信が行われていますが
その後の ACK (No.16) では Ack=1409 として返答が行われていることが分かり、
通信が正常に行われていないことがここから読み取れます。
またこの 1475 bytes でないパケットについては先述の VM-01 のキャプチャにおいては確認出来ず、その後発生した No.25 の Ack に対する No.26 の 1474 bytes の通信が行われて初めて VM-01 側にパケットが到達しているように見受けられます。
MTU9000 の時の CAP-01 のキャプチャ
上記のようになります。
インターネットを介して No.10 ~ No.19 に掛けて勢いよく通信が行われていますが
その後 No.20 において Ack=1 が返され、No.23 において再送が行われています。
この間 Seq は 12673 まで増えており、この No.19 に当該するパケットは先述の CAP-02 においても No.21 として観測できているように見受けられます。
以上の事象、また CAP-02 においてパケットをとり続けると、 reassemble されたパケットが送信された後に再送要求が発生していること、そして RSC を Disable にするとこれらの事象が解決することから RSC (LRO) が原因と判断しました。
また繰り返しではありますが、
Windows Server 2022 (Preview) や Windows 10 (21H1) では発生しないことを確認していますので Windows Server 2019 特有の問題 ( 1809 ベースの Hyper-V 特有? ) と判断しています。
番外：ドライバベースで治せないかやってみる
Linux のドライバは自由に修正したりして実験できますので、
これで何か出来ないかやってみます。
１．そもそも機能を切る:
netvsc の 603 行目に下記のような記述があります
https://github.com/torvalds/linux/blob/master/drivers/net/hyperv/netvsc.c#L603
/* Negotiate NVSP protocol version */
static int negotiate_nvsp_ver(struct hv_device *device,
struct netvsc_device *net_device,
struct nvsp_message *init_packet,
u32 nvsp_ver)
{
/// 省略 ///
if (nvsp_ver >= NVSP_PROTOCOL_VERSION_61)
init_packet->msg.v2_msg.send_ndis_config.capability.rsc = 1;
/// 省略 ///
return ret;
}この nvsp_ver で Windows Server 2019 とそれ以降の区別を試みましたが
共に NVSP_PROTOCOL_VERSION_61 (0x60001) が返るため、区別は出来ませんでした。
もちろんですが、”init_packet->msg.v2_msg.send_ndis_config.capability.rsc = 0;” とすると RSC の機能が恒久的に無効になります。
２．別パラメータから値を推測する等で値を修正する：
こちらですが、そもそも VMBus 経由での VMQ の割込が来ないため
修正は難しいという形になりました。
Hyper-V のネットワーク通信は下記のようなアーキテクチャになっています。
引用元 : https://docs.microsoft.com/ja-jp/windows-hardware/drivers/network/vmq-components
親（ホスト）が持つ NetVSP (VMSwitch) に対して VMBus 経由で接続するアーキテクチャになっており、Linux の netvsc ドライバにおいても 1665 行目付近でその接続が行われていることが伺えます。
struct netvsc_device *netvsc_device_add(struct hv_device *device,
const struct netvsc_device_info *device_info)
{
/// 省略 ///
/* Enable NAPI handler before init callbacks */
netif_napi_add(ndev, &net_device->chan_table[0].napi,
netvsc_poll, NAPI_POLL_WEIGHT);
/* Open the channel */
device->channel->rqstor_size = netvsc_rqstor_size(netvsc_ring_bytes);
ret = vmbus_open(device->channel, netvsc_ring_bytes,
netvsc_ring_bytes, NULL, 0,
netvsc_channel_cb, net_device->chan_table);
if (ret != 0) {
netdev_err(ndev, "unable to open channel: %d\n", ret);
goto cleanup;
}
/* Channel is opened */
netdev_dbg(ndev, "hv_netvsc channel opened successfully\n");
napi_enable(&net_device->chan_table[0].napi);
/* Connect with the NetVsp */
ret = netvsc_connect_vsp(device, net_device, device_info);
if (ret != 0) {
netdev_err(ndev,
"unable to connect to NetVSP - %d\n", ret);
goto close;
}
/// 省略 ///
}試しに netvsc_receive 関数を下記のように編集してみると下記のような出力が得られました。
static int netvsc_receive(struct net_device *ndev,
struct netvsc_device *net_device,
struct netvsc_channel *nvchan,
const struct vmpacket_descriptor *desc)
{
struct net_device_context *net_device_ctx = netdev_priv(ndev);
struct vmbus_channel *channel = nvchan->channel;
const struct vmtransfer_page_packet_header *vmxferpage_packet
= container_of(desc, const struct vmtransfer_page_packet_header, d);
const struct nvsp_message *nvsp = hv_pkt_data(desc);
u32 msglen = hv_pkt_datalen(desc);
u16 q_idx = channel->offermsg.offer.sub_channel_index;
char *recv_buf = net_device->recv_buf;
u32 status = NVSP_STAT_SUCCESS;
int i;
int count = 0;
// 下記行を追記
netif_info(netdevice_ctx, rx_err, ndev, "BUF-SIZE : %u, SEC-SIZE : %u, RSC-PKTLEN %u\n",
net_device->recv_buf_size, net_device->recv_section_size,
nvchan->rsc.pktlen);
/* Ensure packet is big enough to read header fields */
if (msglen < sizeof(struct nvsp_message_header)) {
netif_err(net_device_ctx, rx_err, ndev,
"invalid nvsp header, length too small: %u\n",
msglen);
return 0;
}
/// 以下省略 ///
BUF-SIZE が Window Size にちょっと足したもの、SEC-SIZE が MTU にちょっと足したものの値になり、 RSC-PKTLEN がフレームサイズと同じ値を指し示すようです。
RSC-PKTLEN の値は 1474 を示しており、冒頭のパケットキャプチャと同じような感じになっていることが読み取れます。
なお、同じ VM を同じ設定で Windows 10 の上に構築した場合は下記のようになります。
RSC-PKTLEN が十分に大きな値になっており、 RSC にて reassemble されたパケットが受信出来ていることが分かります。
ドライバを追いかけてみたのですが、正しい値が別パラメータに入っていることなどはなく、また NetVSP の割込が来ないため修正は難しいと考えられました。
まとめ
Windows Server 2019 の Hyper-V を使用して VM を作成する場合は
・MTU を 1500 以下に設定して RSO が正常に機能するようにして使う
・Jumbo Frame を有効にしたい場合は RSO を Disable にする
のどちらかで利用しないと、落とし穴があるという話です。
執筆時点の最新版である “10.0.17763.1999” でもこの事象は発生していますので、
お気をつけくださいませ。
P.S.
割と海外のフォーラムだと “RSO を無効にしたら良くなった！” 的なのはちらほら報告されているみたいですね。。修正されたらいいなとぼんやり思ってます。。