Revisiting the Open vSwitch Dataplane Ten Years Later 3

본 포스트는 sigcomm '21의 Revisiting the Open vSwitch Dataplane Ten Years Later를 요약하였습니다.

 

이전 포스트: https://byeo.tistory.com/entry/Revisiting-the-Open-vSwitch-Dataplane-Ten-Years-Later-2

Revisiting the Open vSwitch Dataplane Ten Years Later 2

 

 

 

요약이라는 목적을 갖고, 앞에서 언급한 내용을 환기한다던가 혹은 필요 없다고 판단하는 내용을 줄이고 있는데 여전히 긴 것 같습니다... 중요도가 떨어지는 내용은 더 쳐내보도록 노력해야겠습니다. 

 

5. Performance Evaluation

• 2 Intel Xeon E5 2440 v2 2.4 GHz servers, 각각 CPU 8 cores.
• back-to-back connected
• hyperthreading enabled
• kernel 5.3.0
• 10 GbE X540 dual port NICs

 

 총 3개의 환경을 실험: 각각의 서버에 VM이 1개씩 있고 이들 간의 통신 (inter-host VM-to-VM), 동일 서버 내 VM 2 대간 통신 (intra-host VM-toVM), 그리고 컨테이너 (intra-host container-to-container)

각 시나리오당 '기존처럼 user/kernel split의 ovs dp', 'AF_XDP' 를 측정. DPDK는 거의 사용하지 않아서 측정하지 않았다.

측정은 iperf3으로 진행하였다. 

 ovs rule은 Geneve Encapsulation을 사용하여, 터널링 과정이 packet processing에 추가된다. 또한 conntrack을 포함하고 약 103,000개의 openflow rule이 구성된 환경에서 테스트하였다.

 

Figure 8(a)는 inter-host VM-VM을 나타낸다.

• 첫 번째 막대는 기존 kernel logic이며, tap device를 사용했을 때: 2.2 Gbps
• 두 번째 막대는 AF_XDP에서 interrupt 기반으로 동작할 때: 1.9 Gbps
• 세 번째 막대는 polling기반 AF_XDP 으로 동작한 것이며, O4까지 적용했을 때: 3 Gbps
• 네 번째 막대는 vhostuser를 사용했을 때: 4.4 Gbps
• 다섯 번째 막대는 checksum offload를 가정하여 추정했을 때: 6.5 Gbps

Figure 8(b)는 intra VM-VM을 나타낸다.

• 첫 번째 막대는 기존 kernel logic이며, tap device를 사용했을 때: 12 Gbps (TSO와 checksum 오프로드 영향때문에 높게 나온 것)
• 두 번째 막대는 AF_XDP에서 tap device를 사용했을 때: 가장 낮음 (수치가 제시되지 않았다.)
• 세 번째 막대는 vhostuser를 사용했고, offloading이 없을 때: 3.8 Gbps
• 네 번째 막대는 checksum offloading시: 8.4 Gbps
• 다섯 번째 막대는 TSO까지 사용할 때: 29 Gbps

다섯 번째 막대는 기존 커널과 비교하여 상당히 높은데, 이는 vhostuser를 사용하면 packet이 QEMU process에게 전달할 때 kernel을 거치지 않기 때문이다.

 

Figure 8(c)는 container-cotainer를 나타낸다.

• 스킵

결론: VM에서는 OVS AF_XDP가 in-kernel OVS와 비교하여, intra VM에서는 2.4배, inter VM에서는 3배 더 좋은 성능을 보였다.  container에서는 OVS AF_XDP가 in-kernel OVS보다 성능이 좋지 못했는데, 이는 AF_XDP가 TSO를 지원하게 된다면 이 차이를 줄일 수 있으리라 기대한다.

 

5.2 Packet Forwarding Rate

 이번 섹션에서는 raw 성능을 측정한다. 

• 2 Intel Xeon E5 2620 v3 2.4 GHz servers, 각각 CPU 12 cores.
• back-to-back connected
• 25 Gbps Connect-X6 DX
• 한쪽에서는 Trex를 통해 트래픽을 생성, 반대쪽에서는 호스트에서 수신하거나 또는 2 vCPUs 4GB memory를 가진 VM에서 수신한다. 

이 실험에서는 in-kernel OVS dp, AF_XDP dp, DPDK dp를 측정하였다. 실험에서는 packet이 loss없이 보내지는 최대의 pps를 찾아 그 상황에서 CPU 사용량을 측정하였다. flow 개수는 1개와 1,000개를 실험하였다. 1,000개는 ovs dp cache에 상당한 miss rate를 야기함에 따라 worst case라고 볼 수 있다. packet size는 64 bytes다. 

 

 Figure 9 (a)는 packet을 수신한 서버가 곧바로 다른 physical port (이하 PF)로 forwarding하는 케이스이다. overhead가 가장 적은 케이스라고 볼 수 있다.

  userspace dp case에서는 1,000 flows의 케이스가 1 flow 케이스보다 안좋은 것을 확인할 수 있다. 이는 kernel dp를 사용할 때에만 RSS의 지원을 받아 여러 코어에게 적절히 분산시켜주기 때문. 덕분에 kernel dp의 1,000 flows는 CPU 사용량이 상당한 것을 볼 수 있다. 

 

 Figure 9 (b)는 PF-VM-PF의 경우로, VM을 거치는 round trip이 추가된다. VM에게 연결할 때에는 kernel의 tap device, DPDK는 vhostuser, AF_XDP는 tap/vhostuser를 모두 측정하였다. 

 그래프에서 보이듯, vhostuser는 pps와 CPU 사용량 측면에서 항상 tap보다 좋은 모습을 보인다.

 vhostuser에서 AF_XDP는 DPDK보다 30%낮은 성능을 보였다. 

 CPU 사용량은 userspace dp에서 모두 고만고만한데, 이는 CPU affinity를 지정해놓았기 때문.

 in-kernel dp는 RSS의 혜택을 받아도 앞선 PF-PF case와는 다르게 성능을 올리지 못했다. 그 이유는 userspace dp가 사용하는 rx/tx ring의 busy polling, no packet batching, memory pre-alloc, 여러 optimization 등의 기법들을 in-kernel dp가 상용할 수 없었기 때문이다. 

 

 Figure 9 (c)는 PF-container-PF의 경우로, AF_XDP를 사용 시 figure 5 (c) path를 흐름에 따라 좋은 성능을 얻을 수 있었다 (packet을 in-kernel에서 처리). 또한, DPDK와 비교해서는 userspace-to-kernel DPDK 비용 (veth로 넣어주는 비용으로 보인다)을 XDP에서는 피함에 따라 성능이 더 좋다.

 

 

 Table 4는 Figure 9에서 1,000 flows를 실험했을 때의 CPU 사용량을 CPU hyperthread개수로 평균내어 breakdown한 것이다. 

 system과 softirq는 host kernl time, guest는 VM 내의 time, user는 OVS userspace를 포함해 host user가 사용한 time을 의미한다. in-kernel ovs dp는 대부분 kernel의 CPU를 사용하고, DPDK 설정은 대부분 user에서 사용한다. 그리고 AF_XDP는 그 중간에 위치한 것을 알 수 있다.

 

결론: 수신측이 container일 경우 OVS AF_XDP가 가장 좋은 성능을 보인다. 그 외에는 DPDK가 가장 좋은 성능을 보인다. 단, socket polling, memory mgmt, zero-copy등이 kernel내에 잘 포함된다면, AF_XDP의 softirq CPU 사용량이 함께 줄어들어 DPDK보다 더 적은 CPU 사용량을 보이게 될 것이라고 기대한다.

 

 

5.3 Latency and Transaction Rate

 5.2와 동일한 실험 환경에서 netperf's TCP_RR test ( client와 server 사이에서 1 byte packet을 빠르게 주고받는 테스트를 수행해 latency 측정 및 분포 제공) 진행하였다.

 

• Kernel: OVS가 VM의 tap device, Container의 veth를 이용
• DPDK: OVS가 dpdk mlx5 driver를 이용, vhostuser를 이용해서 VM에 연결, DPDK_AFPACKET을 이용해서 container에 연결
• AF_XDP: VM은 vhostuser를 통해서 연결, container는 XDP program을 사용해 vhostuser로 연결

 

 Figure 9는 Intra-host 실험이다. polling과 interrupt를 적절하게 선택하는 Kernel의 경우 50th/90th/99th latency는 각각 58/68/94 us였다. DPDK는 polling mode에 의해서 성능이 더 좋아 36/38/45 us를 보였다. AF_XDP는 39/41/53 us를 보였다. DPDK보다 살짝 느린데, 이는 hardware checksum support의 부재에 의한 것이다.

 

 Figure 10은 Intra-host container 테스트이다. AF_XDP는 15/16/20 us를, DPDK는 81/136/241 us를 보였다. 이는 계속 설명하듯 DPDK의 경우 추가로 user/kernel transition을 요구하기 때문이다.

 

결론: OVS AF_XDP가 in-kernel 혹은 DPDK 보다 latency 측면에서 견줄만한 혹은 더 좋은 성능을 보였다.

 

5.4 XDP processing 비용

Section 5.1과 5.2에서는 userspace OVS dp가 PF를 통해 모든 트래픽을 수신하고 처리했다. 이는 XDP program을 최소한만 사용하기 위함.

 이 section에서는 5.1의 환경에서 NIC driver XDP에 새로운 feature를 추가하여 비용을 알아보고자 한다. Single core에서 P4로 생성된 XDP 프로그램의 flow processing logic을 추가하여 비용을 비교한다.

 

 

 Table 5는 여러 상황들에 대한 결과를 보여준다. XDP program의 복잡도가 증가할수록 성능은 하락하는 것을 볼 수 있다. 

Task B는 CPU가 데이터를 더 읽어야 하고, Task C는 eBPF map 자료구조를 사용해야 하며, Task D는 packet을 수정까지 해야 한다.

 

결론: XDP 코드의 복잡도는 성능을 하락시킨다. userspace AF_XDP에서의 packet processing은 XDP에서 처리하는 것보다 항상 느린 것은 아니다. (결론이 와닿지가 않는데, 아무튼 table 2의 O5보다 더 빠르다 이건가?)

 

5.5 Multi-Queue Scaling

 

 Figure 12는 5.2와 유사한 환경에서 Trex를 사용해 트래픽을 발생시켰을 때, PMD thread 개수 및 PF의 rx queue 설정 개수가 어떤 영향을 가져오는지 나타낸 그래프다. Packet bytes는 64B, 1518B를 line rate로 쐈으며, 이는 각각 33 Mpps, 2.1 Mpps에 해당한다. 

 1518B packet의 경우, OVS AF_XDP는 6개의 queue를 사용했을 때 25 Gbps를 달성할 수 있었다. 64B packet의 경우에는 큐의 개수에 상관없이 AF_XDP가 DPDK를 이길수는 없었다. 

 

 6개의 PMD queue를 설정했을 때, OVS AF_XDP와 DPDK의 성능 차이를 밝혀내기 위해서 Linux perf로 분석을 해보았다. 분석해보니 OVS AF_XDP에는 2가지 비용이 존재했다: (1) packet 전송을 위한 kernel context switch, (2) RSS를 위한 rxhash값 계산 (h/w offloading이 없기 때문)

 

결론: AF_XDP는 아직 DPDK를 이기지는 못한다. 하지만 25 Gbps를 달성할 수 있을만한 성능은 내고있다.

 

6. 교훈

1) 위험 줄이기. kernel module은 어떠한 버그가 발생하면 host 자체와 그 위에서 돌아가는 소프트웨어를 모두 죽여버린다는 위험이 도사린다. 이에 반해, OVS AF_XDP는 오로지 OVS process만 kill을 한다는 장점이 있고 이마저도 재시작이 가능해서 복구가 빠르다. 

 

2) 쉬운 개발. 모든 커널 버전에 맞춰서 kernel module을 빌드하고 검증하는 것은 굉장히 어렵다. AF_XDP를 사용한다면 개발팀이 이러한 어려움을 겪을 일이 없다.

 

3) 쉬운 업그레이드와 패치. in-kernel OVS dp를 업그레이드/패치하는 것은 kernel module을 reload하고 전체 시스템을 재부팅해야 한다. 하지만 AF_XDP라면 OVS만 재시작해도 된다.

 

4) 쉬운 개발. SDN 환경에서의 kernel module 수정, 컴파일, 로드는 크래쉬 위험과 재부팅의 필요때문에 개발, 테스트, 배포를 어렵게 만든다. AF_XDP에서는 낮아진 개발 난이도 덕분에 dp에 더 많은 기능이 추가되리라 예상한다.

 

5) 쉬운 트러블 슈팅. 실제 데이터센터는 수천~수만 개의 OpenFlow rule을 사용하고 있고, 그에 터널링 (Geneve)과 conntrack까지 사용중이다. 이러한 복잡한 구성은 네트워크 설정을 verification하는데 어렵게 만든다. 이를 userspace에서 구현한다면 테스트/디버깅이 더 쉬워질 것이다.

 

6) 쉬운 패키징과 검증. 모든 Linux Kernel은 AF_XDP를 포함하고 있다. 따라서 OVS AF_XDP는 특정 linux kernel version이나 DPDK version에 얽매이지 않는다. OVS는 valgrind와 같은 여러 code analysis tool을 사용하는데, user/kernel split design에서는 각각에 대해서 tool을 돌려야 했다. 또한, github action과 같은 CI/CD tool들은 root 권한이 필요한 kernel module load 테스트는 할 수 없었다. OVS AF_XDP는 userspace이기 때문에 CI/CD의 혜택을 받을 수 있으리라 예상한다.

 

7) 더 좋은 cross-platform 디자인. NSX의 고객은 때때로 Oracle Linux와 같은 비주류 Linux distribution을 실행할 때가 있다. 이들은 kernel의 내부 행동의 일부를 다르게 변경하여 OVS kernel module과 호환이 되지 않기도 한다. OVS AF_XDP는 대부분 userpsace이며, 최소한만 OS kernel에 의존하고 있기 때문에 다른 OS로의 포팅이 더 쉬워질 것이라 예상한다.

 

8) (단점) 일부 기능은 재구현되어야 함. Linux netowrk stack의 conntrack, firewall, NAT, tuinnel encapsulation와 같은 기존 기능들은 In-kernel OVS의 경우에는 누릴 수 있었다. 하지만 userspace로 올리는 경우에는 이들을 모두 재구현해야한다. QoS와 같은 경우도 기존에는 traffic shaping을 통해서 수행했으나, 기능이 없어서 openflow metering으로 대체하고 있다. 이에 대한 해답은 찾아나갈 예정

 

9) (단점) window는 AF_XDP를 아직 지원하지 않음. OVS는 Windows-specific kernel driver와 Winsock을 통해서 window를 지원한다. 아직 AF_XDP는 지원하지 않으나, Microsoft의 공지에 따르면 조만간 eBPF for Windows 프로젝트를 진행한다고 한다 (JIT로서 uBPF를 사용, PREVAIL verifier를 사용). 따라서 곧 AF_XDP도 가능해질 것이라 기대한다.

 

10) (단점) AF_XDP가 항상 빠른 선택지는 아니다. OVS AF_XDP + vhostuser 인터페이스는 VM 내에서의 application을 위한 가장 빠른 선택지이다. 또한, XDP의 redirection 기능은 container-to-container UDP workloads에서 가장 빠른 선택지를 제공한다. 하지만, in-kernel OVS가 여전히 OVS with AF_XDP container-to-container TCP workloads에서는 가장 빠르다. 이는 추후에 AF_XDP가 TSO를 사용할 수 있게 된다면 바뀔 것이라 기대한다.

 

8. 결론

 이 논문은 OVS를 지원하고 실행하면서 쌓은 경험들을 공유하였다. Linux kernel과 강하게 결합된 OVS는 다음과 같은 단점들이 존재한다. (1) OVS에 기능을 개발하는데 Linux developer들로부터 승인을 받아야한다. (2) OVS upgrade 혹은 버그 수정이 kernel module에 영향을 주고, 이는 커널 업데이트 혹은 재부팅을 필요로 한다. (3) 전통적인 in-kernel packet processing은 새로운 선택지보다 상당히 느리다.

 

 우리는 Linux networking의 진보 기술인 AF_XDP와 같은 기능을 접목하여 NIC에 도착하자마자 userspace로 packet을 전송하는 방법을 제안하였다. OVS DPDK와 성능을 견줄만한 것을 보였음 외에도 이 논문에서 제안한 방식은 새로운 버전에을 검증하고 테스트하는데 더 용이하다는 점이 있다. 새로운 코드는 OVS mainstream repository에 이미 merge되었다.