document-haness/docs/virtualization/tech-log-studio/network-virtualization/question/question-virtio-net-multi-queue-enabled.md

id, kind, slug, title, topic, topicName, project, status, questionStatus, studio, sourceRevision, source

id	kind	slug	title	topic	topicName	project	status	questionStatus	studio	sourceRevision	source
1a996f8d-b04e-49d2-88ef-4877e21f7c0e	QUESTION	virtio-net-multi-queue-enabled	이 가상 머신들의 virtio-net 에 multi-queue 가 켜져 있는가	network-virtualization	네트워크 가상화	virtualization	초안	OPEN	https://hyeonworks.com/studio/documents/1a996f8d-b04e-49d2-88ef-4877e21f7c0e/edit	no-commit · 밖에서 반입한 문서 한 편. 고정할 저장소 리비전이 없다	final/document.md#122-open-question-oq-5 final/document.md#112-multi-queue-최적화 final/document.md#100-virtqueue의-역할 final/document.md#117-이-구조에서-발생할-수-있는-문제-117-5

이 가상 머신들의 virtio-net 에 multi-queue 가 켜져 있는가

multi-queue 는 virtio-net 이 송수신 큐를 여러 개 두고 쓰는 구성이다. §112 는 큐를 하나만 쓰면 패킷 처리가 한 vCPU 나 한 처리 경로에 몰릴 수 있어서 이것을 최적화 방향으로 들었을 뿐, 이 가상 머신들의 큐 수는 적지 않았다. 이 물음은 그 쏠림이 실제로 일어나는지를 재지 않고, 두 대가 애초에 큐를 몇 개 쓰도록 구성되어 있는지를 읽는다.

관계

• Guest 의 packet 이 Host Physical NIC 에 닿기까지 — virtio-net · virtqueue · vhost-net · TAP · Bridge 게스트와 호스트 백엔드가 virtqueue 로 무엇을 주고받는지를 이 개념이 설명한다. 큐를 몇 개 두느냐는 그 구조 위의 설정이다.
• 이 호스트에서 vhost-net 이 실제로 packet datapath 를 맡고 있는가 큐를 실제로 돌리는 백엔드가 어느 쪽이냐에 따라 큐 수를 읽을 곳이 달라진다.
• 부하 중 network 가상화가 지연을 바꿀 만큼 호스트 CPU 를 쓰는가 큐가 하나로 나왔을 때 그것이 실제 병목인지는 부하 구간의 vCPU 별 사용량이 답한다.

사실

• §112 는 큐를 하나만 쓰면 특정 vCPU 나 처리 경로에 부하가 몰릴 수 있다고 적었고, virtio-net 이 multi-queue 를 쓸 수 있다고 밝혔다. 든 예는 RX Queue 0 부터 3 까지를 vCPU 0 부터 3 까지에 하나씩 대응시킨 구성이다.
• §112 가 적은 multi-queue 의 목적 셋 Packet processing 병렬화 Single queue bottleneck 완화 Multi-core 활용
• §112 는 그 효과가 workload · CPU affinity · IRQ placement · queue configuration 에 따라 달라진다고 덧붙였다. IRQ(Interrupt Request, 인터럽트 요청)는 장치가 처리할 일이 생겼음을 CPU 에 알리는 신호다.
• §100 은 virtqueue 를 게스트와 호스트 백엔드가 디스크립터(descriptor)를 써서 I/O 버퍼를 주고받는 공유 큐 구조로 놓고, 네트워크에서는 보통 TX/RX 큐를 쓴다고 적었다. TX virtqueue 는 게스트에서 호스트로, RX virtqueue 는 호스트에서 게스트로 버퍼를 넘긴다.
• §117.5 는 single queue bottleneck 을 큐 하나나 vCPU 하나에 패킷 처리가 몰리는 문제로 놓고, 확인 대상 넷을 들었다. virtio multi-queue IRQ distribution per-vCPU CPU usage RSS/RPS/XPS
• §122 OQ-5 가 적은 확인 대상 넷 QEMU/libvirt NIC configuration Guest ethtool queue count IRQ distribution
• 같은 §122 에서 OQ-1 과 OQ-2 는 돌릴 명령을 그대로 적었고, OQ-5 는 확인 대상 넷의 이름만 적었다. §117.5 가 든 넷도 이름이다.
• §197 과 §218 은 이 실험대의 vCPU 배분을 실측으로 적었다. k3s 노드 kc-lab-1 과 kc-lab-2 가 각각 vCPU 2 이고 엣지 게스트가 1 이며, 합 5 를 논리 코어 8 위에 얹었다. §112 가 큐와 vCPU 를 하나씩 짝지어 든 예는 넷씩이라 이 게스트들의 수와 다르다.
• §247 은 VM 이 부팅하면 게스트 커널이 virtio NIC 를 인식하고 DHCP 클라이언트가 DHCPDISCOVER 를 브로드캐스트한다고 적었다. 이 게스트들의 NIC 가 virtio 라는 것은 거기까지 나온다.
• §201 은 게스트 안에서 본 인터페이스 이름을 한 줄 남겼다. 엣지 게스트가 첫 부팅에서 enp1s0 으로 192.168.122.10/24 을 받았다. ethtool 에 넣을 이름이 그 줄에서 나오지만 k3s 노드 두 대의 인터페이스 이름은 적혀 있지 않다.
• 두 가상 머신에 설정된 큐 수가 SSOT 에 없다. 게스트가 몇 개를 쓰고 있는지도, IRQ 가 어느 vCPU 에 붙어 있는지도 적혀 있지 않다.
• §126 이 적은 실습 순서 열둘 가운데 multi-queue / offload 확인은 마지막 열두째다.
• 네트워크 계층의 확인 명령을 모아 둔 §118 에는 큐 수나 IRQ 분포를 읽는 명령이 없다. Guest NIC 항목에 적힌 것은 ip link · ip addr · ip route · ip neigh 이고, virtio 장치 항목은 lspci 와 lsmod | grep virtio 다. ethtool 은 Physical NIC 항목에서 인터페이스 이름을 받는 형태로만 나온다.

가정

• 두 가상 머신의 구성과 게스트 내부를 지금 읽을 수 있다고 본다.
• §112 가 든 RX Queue 넷과 vCPU 넷의 짝은 multi-queue 를 설명하려고 든 예시이지 이 호스트에서 읽은 값이 아니다.
• 설정에 적힌 큐 수와 게스트가 실제로 쓰는 큐 수를 따로 읽어야 한다고 전제한다. 설정에 여럿을 적어 두면 게스트 드라이버가 그만큼 쓴다는 서술이 근거 문서에 없기 때문이다.
• 큐를 여럿 두어도 IRQ 를 한 vCPU 가 몰아서 받으면 처리가 한쪽에 몰린다고 본다. §117.5 는 IRQ distribution 을 확인 대상으로 들었을 뿐 그렇게 된다고 적지는 않았다.
• 두 가상 머신의 NIC 구성이 확인하는 동안 바뀌지 않는다.

미지수

• 두 가상 머신의 virtio-net 에 설정된 큐 수.
• 게스트가 실제로 쓰고 있는 큐 수, 그리고 그 수가 설정값과 같은지.
• 각 큐의 IRQ 가 여러 vCPU 에 흩어져 있는지 한 vCPU 에 몰려 있는지.
• 설정된 큐 수와 vCPU 수의 관계. vCPU 는 §218 이 두 노드 모두 2 로 적었으므로, 큐가 몇이면 §112 가 든 하나씩 대응이 되는지는 큐 수를 읽어야 갈린다.
• 이 환경의 RSS/RPS/XPS 설정. §117.5 가 확인 대상으로 들었지만 값을 읽는 방법은 적지 않았다.

제약

• 이 호스트에서 잰 값이 하나도 없다. 근거는 개념을 정리한 문서 한 편이고 §112 의 큐 넷과 vCPU 넷은 예시 숫자다.
• 이 물음은 큐 구성이 무엇인지까지만 답한다. 쏠림이 실제 병목인지는 부하를 걸어야 갈리고, 그 부하 측정은 다른 물음이 가져간다.
• 확인하는 동안 NIC 구성을 바꾸지 않는다. 큐 수를 늘려 놓고 읽으면 지금 실험이 어떤 구성에서 돌았는지 못 본다.
• 게스트 안에서 읽는 항목이 둘이라 게스트가 떠 있어야 한다. SSOT 가 마지막으로 적은 게스트 상태는 §202 의 철거이고, 그 뒤 다시 세웠는지는 적혀 있지 않다.
• §118 이 큐 수와 IRQ 분포를 읽는 명령을 적지 않았으므로, 실행한 명령과 그 출력을 함께 증거로 남겨야 다음 사람이 같은 값을 다시 읽는다.

선택지

1. 호스트 쪽 설정값만 먼저 읽는다

libvirt 와 QEMU 쪽 NIC 구성에 큐 수가 적혀 있는지부터 본다. §90.2 가 libvirt 의 관리 대상 예로 든 여덟은 vCPU · Memory · Disk · NIC model · MAC address · Virtual network · Bridge · QEMU arguments 이고, 큐 수는 그 목록에 없다. 가상 머신에 들어가지 않고 호스트에서 끝나고, 큐가 하나로 적혀 있으면 그 구성은 single queue 로 확정된다.

설정에 큐를 여럿 적어 두었을 때 게스트가 그만큼 쓰는지는 이 확인으로 알 수 없다.

2. 설정값과 게스트 쪽 채널 수를 함께 읽는다

§122 OQ-5 가 든 넷 가운데 앞의 셋에 해당한다. 호스트의 NIC 구성과 게스트 안에서 본 채널 수를 같이 적으면 둘이 어긋나는 경우까지 잡힌다. 가상 머신 두 대에 각각 들어가야 해서 실행 횟수가 늘어난다.

3. IRQ 분포까지 한 번에 읽는다

큐가 여럿이어도 IRQ 가 한 vCPU 에 몰려 있으면 §117.5 가 든 쏠림은 그대로 생길 수 있다. §122 OQ-5 가 IRQ distribution 을 넷째 확인 대상으로 둔 이유가 여기에 있다. 세 항목을 한 번에 받아 적으면 큐 수만으로 판정을 끝내지 않게 된다.

4. 제외 — 큐 수를 바꿔 가며 견준다

multi-queue 를 켜고 끄면서 재면 이 환경에서 큐 수가 무엇을 바꾸는지 바로 보인다. 그러나 지금 물음은 실험이 어떤 구성에서 돌고 있는지를 읽는 것이라, 구성을 바꾸고 잰 값은 답이 되지 않는다. 켜고 끈 두 구성을 견주는 측정은 별도 Case 로 뺀다.

다음 검증

1. 호스트에서 두 가상 머신의 libvirt/QEMU NIC configuration 을 열어 큐 수가 적혀 있는지 읽는다. §122 에서 libvirt domain XML 을 확인하라고 적은 곳은 OQ-3 이고 OQ-5 에는 그 문장이 없다. §118 이 이 확인의 명령을 적지 않았으므로 무엇을 실행했는지 함께 기록한다.
2. 각 게스트에서 ethtool 로 채널 수를 읽고, 실제 queue count 를 그 옆에 적는다. §122 OQ-5 가 Guest ethtool 과 queue count 를 나눠 적었으므로 둘을 따로 남긴다.
3. 각 게스트의 IRQ 분포를 읽어 큐마다 어느 vCPU 에 붙어 있는지 적는다.
4. 두 가상 머신의 결과를 vCPU 수와 나란히 한 표로 정리한다.

닫는 조건 : 가상 머신마다 설정된 큐 수 · 게스트가 쓰는 큐 수 · IRQ 분포를 한 표로 적으면 닫는다. 큐가 하나로 나오면 §117.5 가 든 single queue bottleneck 이 이 환경에서도 일어날 수 있는 구성이라고 적는다. 그것이 실제 병목인지는 부하를 건 뒤 vCPU 별 CPU 사용량이 답하기 때문에 「부하 중 network 가상화가 지연을 바꿀 만큼 호스트 CPU 를 쓰는가」로 넘긴다. 큐가 여럿이고 IRQ 도 흩어져 있으면 이 항목은 지금 실험에서 우선순위를 낮추고 닫는다.