Understanding PCIe performance for end host networking 3

해당 포스트는 Sigcomm '18의 Understanding PCIe performance for end host networking 을 번역하여 정리한 글입니다.

 

Understanding PCIe performance for end host networking 1: https://byeo.tistory.com/entry/Understanding-PCIe-Performance-for-end-host-networking-1

Understanding PCIe performance for end host networking 1

Understanding PCIe performance for end host networking 1: https://byeo.tistory.com/entry/Understanding-PCIe-Performance-for-end-host-networking-2

Understanding PCIe performance for end host networking 2 (PCIe 프로토콜)

 

5. Implementations

pci-bench는 PCIe device의 DMA 엔진에 대한 programmablity와 정교한 제어를 필요로 한다. Netronome과 NetFPGA board 두 가지 장비를 대상으로 구현하여 테스트 하였다.

5.1 Netronome NFP implementation

• NFP-6000과 NFP-4000은 최대 120개의 8-way 멀티스레드 Flow Processing Cores와 함께 계층형 메모리 시스템을 제공한다. PCIe subsystem은 FPC에게 'register를 이용해 작은 PCIe read와 write transaction을 발생시킬 수 있는 command' 기반과 'host memory와 NFP memory 사이에서 bulk DMA를 할 수 있도록 해주는 interface' 두 가지를 제공한다.
• pcie-bench는 FPC에 firmware로서 구현되었다.

 

Firmware.

• PCIe-bench의 모든 기능은 하나의 firwmare image로서 구현되었다. 이 firwmare는 user space program에게 어떤 종류의 benchmark를 실행하고 parameter를 건네줄 것인지 쉽게 제어할 수 있도록 제공한다. Parameter의 예시로서는 host buffer 위치, transfer size 등을 넘겨줄 수 있다.
• Benchmark 결과는 NFP memory에 기록되며, host가 다시 읽어갈 수 있다.
• Latency는 FPC에서 single thread로서 측정된다. 이 thread는 사용할 host address를 계산하고 DMA descriptor를 준비한다. 그리고 내부에 있는 timestamp의 값을 읽어서 DMA descriptor에 저장한다. DMA가 완료되면 이 시간 차를 계산하고 NFP에 보관한다. (이 방법말고도, PCI command interface를 이용하여 작은 크기 교환의 latency도 측정할 수 있다.)
• NFP core는 1.2 GHz이고 timestamp은 16 clock cycles마다 증가함에 따라 19.2ns 단위의 latency를 제공한다.
• Bandwidth 측정에서의 어려운 점은 DMA descriptor가 DMA engine에 꾸준히 유입되도록 하여 idle상태가 없도록 해야한다는 점이다. 이를 작은 크기에서도 측정하기 위해 12 core 8 thread의 DMA worker를 사용하였다. 
• 매 loop마다 각 DMA worker thread는 host address를 계산하고 DMA descriptor를 준비하고 실행하며, completion signal이 올 때까지 기다린다. 
• 각 thread들은 atomic counter를 공유하며, 새로운 DMA request를 issue할 때마다 1씩 감소시킨다. 이 값이 0이 되면 worekr는 정지한다.
• BW_RDWR 테스트에서는 각 worker들이 'atomic counter가 짝수일 때는 read'를, 'atomic counter가 홀수일 때는 write'를 issue한다.
• bandwidth와 latency 실험에서는 내부의 256 KB SRAM (Cluster Target Memory라고 알려진)을 타겟으로 하도록 DMA descriptor가 설정되었다. 이 메모리 접근은 50~100 cycles의 latency를 가지며, DMA descriptor enqueue도 유사하다. 이 overhead는 다른 NIC에서도 유사할 것이라고 예상한다. 
• 이 Firmware는 NFP를 위한 확장 C, Micro-C를 이용해 구현되었다. 약 1500줄로 구성되어 있으며, 별도의 의존성 없이 컴파일 가능하다.

5.2 NetFPGA

•  NetFPGA-SUME 보드를 이용해서 진행, 100Gbps PCIe 속도를 제공하고, 이 보드는 QDRII+와 DDR3 메모리를 추가로 갖고 있으며,  PCIe Gen 3 hard-block을 2개 갖고 있는 Xilinx Virtex-7 FPGA device를 포함하고 있다. 
• PCIe micro-benchmark suite를 FPGA에 곧바로 구현하였다. 해당 시스템은 250 MHz (4ns)의 PCIe core로서 동작하는 free-running counter를 통해서 시간을 관리한다. 
• 매 clock cycle마다 새로운 memory request를 (queuing하는 것이 아니라) 곧바로 DMA engine에게 날리는 방식으로 진행된다.
• Latency test는 DMA read request를 날리기 전의 timestam와 acknowledgment가 도착하고 나서 이후의 시간 차이를 확인한다. 최대 1,000개까지의 결과를 보관 가능하다.
• Bandwidth test는 백만개의 transaction을 수행하고 걸린 시간을 나누어서 계산한다. 해당 결과는 NetFPGA memory에 기록되며, 나중에 host에서 이를 확인할 수 있다.
• FPGA design은 Verilog와 System Verilog를 이요해 구현되었다. 

5.3 Kernel Drivers

•  NFP와 NetFPGA 모두 하드웨어를 초기화, DMA를 위한 host memory 할당, user space program이 pci-bench를 제어하기 위한 접근 권한 제공, 그리고 결과를 수집하기 위하여 kernel driver를 사용한다.
• NFP pcie-bench 드라이버는 표준 NFP kernel driver를 사용한다. 이는 driver에서 4MB 단위로 DMA buffer를 할당한다.
• NetFPGA는 hugetlbfs (1GB단위 page) 혹은 표즌 4KB system page를 사용하여 메모리를 할당한다. 
• 두 드라이버 모두 어떤 NUMA node memory를 사용하여 할당할 것인지 제어할 수 있고, cache를 warm하게 만드는 등의 기능을 제공한다.

5.4 Control Programs

• pcie-bench를 제어하기 위한 user space program. python으로 구현되었으며, cache warming과 같은 작은 기능들은 C로 쓰였다.
• 실험 자체는 2,500개의 test를 4시간에 걸쳐서 실행한다.
• 나머지는 그다지 중요해보이지는 않아서 스킵

5.5 Implementation on other devices

• Netronome NFP와 NetFPGA와 같이 DMA engine에 대한 자세한 제어, programmbility 등을 제공하는 PCIe 장비가 점차 증가하고 있다.
• Intel Xeon Phi coprocessor는 Phi core와 호스트에게 descriptor ring을 통해서 device의 DMA engine을 노출하고 있다. 또한 FPGA가 집적된 NIC의 종류도 증가하고 있는데 Mellanox의 ConnectX-3 Pro, Exablaze NIC을 예로 들 수 있다.
• 이 device들에 pcie-bench를 구현하는 것은 앞서 설명한 NFP, NetFPGA와 동일한 포팅 노력을 필요로 할 것이다.
• Programmability가 없는 commodity NIC에는 pcie-bench의 일부만 구현가능하다. 이들에 대해서는 packet을 송신 및 수신하기 위한 버퍼의 위치를 세심하게 조정한 상태에서의 loopback mode를 사용하여 측정한다. (같은 주소의 packet을 여러번 enqueue하고, 수신 buffer의 window size를 다양하게 조절하는 방식 등으로)
• Latency와 bandwidth의 상대적인 변화는 host side의 PCie 구현에 대해서 insight를 제공하고, buffer address의 alignment를 변화시키는 것은 device의 DMA engine에 대한 한계를 드러낼 수 있다.
• 다만, 이 결과는 programmable PCIe device에서의 측정보다 약간 정확성이 떨어질 수 있는데, 이는 commodity NIC이 항상 descriptor transfer 오버헤드를 포함하기 때문이다.

 

6. 실험

• PCIe gen 3x8 에서 실험. PCIe gen 4에도 동일하게 사용될 수 있으리라고 기대. Xeon E5 processor를 사용. Table 1에 실험 환경을 나열하였다.

6.1 Baseline bandwidth and latency

 

• Figure 4에 NFP-6000과 NetFPGA 구현에서의 baseline throughput을 정리하였다. Model BW는 PCIe physical, data link, transaction layer의 overhead를 추정한 것이다. 그래프의 NFP6000-HSW와 NetFPGA-HSW (하스웰, Table1참조)는 실제로 benchmark를 실행하여 얻은 결과이다. (cache warmed, 8KB host buffer, DMA 영역은 cache line aligned)
• NetFPGA-HSW의 benchmark 결과는 우리의 Model BW와 거의 일치한다. PCIe write는 이론 값보다 약간 높게 측정됐는데, 이는 model이 flwo control message를 고정 overhead로 가정했기 때문. 
• NFP6000-HSW는 read가 model bw보다 약간 낮게 나왔는데, 이는 NFP의 DMA engine이 host의 데이터를 NFP 내부의 internal SRAM으로 으로 전송해야 하는 메모리 계층 overhead가 존재하고, 또한 FPC로부터 접근 가능한 영역의 메모리에 옮겨야 하는 overhead가 추가되기 때문.
• 주목할 부분은 64 bytes와 같이 작은 packet size에서 NFP, NetFPGA 둘 다 40Gbps를 달성하지 못했다는 점이다.

• Figure 5는 latency 측정 실험 결과를 나타낸다. 실험 환경은 위의 bandwidth 실험과 동일하다. 
• NFP-6000의 DMA request latency가 작은 trnasfer size에서는 100ns정도 높고, 그 차이는 transfer size가 커질수록 증가한다. 이 이유로는 (1) DMA descriptor를 DMA engine에 enqueu하는 과정이 NetFPGA 구현에서는 필요가 없고 (NFP가 direct PCIe command interface를 써서 이를 우회하면 NetFPGA와 유사한 latency 달성이 가능하다), (2) 큰 transfer size에서의 상황에서는 NFP6000의 memory system에 의한 비용때문이다. 

6.2 Comparing architectures

• Figure 6은 latency 분포를 나타낸다. 200만번 반복하여 측정한 결과를 CDF로 나타낸 것이다.
• NFP6000-HSW는 520~547ns 영역에 99.9%의 결과가 포함되어 있고, 최대값은 947 ns였다.
• NFP6000-HSW-E3 (Intel Xeon E3)은 상당히 차이가 심한데, 최소값은 493 ns, 중앙값은 1213 ns, 99th는 5,707 ns 였다. 99.9th percentile은 11,987 ns고, 최대는 5.8 ms였다.
• 추정컨대, Intel에서 Xeon E5와 Xeon E3 프로세서의 PCIe root complex를 다르게 관리한 것으로 보이고, hidden power saving mode의 동작 여부 등이 영향을 주었을 것으로 보인다. (Intel Xeon E5에서는 이를 비활성화 했을 때 latency가 안정화 됐다는데, E3에서는 소용이 없었다고 한다.)

 

6.3 Caching and DDIO

• Figure 7은 caching과 DDIO에 따른 효과를 보여준다. 해당 실험에서는 window size (4KB to 64MB) 와 LLC 상태 (15MB or 25MB)를 제외하고는 모두 고정 값이다. Figure 7(a)는 가장 작은 latency를 얻기 위해서 8B 단위로 data를 전송하였다.
• Figure 7(a)에서 PCIe read (LAT_RD)를 보면, cold cache의 경우 window size를 변경해도 latency가 변하지 않음을 볼 수 있다. Cold cache임에 따라 모든 PCIe read는 memory로부터 읽어들이기 때문. Warm cache의 경우에는 read latency가 70ns정도 더 낮지만, LLC size를 초과하는 순간 다시 cold cache와 값이 같아진다. 이는 PCIe read를 할 때, data가 LLC에 있으면 LLC로부터 가져옮을 확인시켜주는 대목이다.
• Write도 유사한 패턴을 보인다. 다만 LAT_WRRD cold cache에서는 DDIO효과가 나타난다. window size가 작을 때에는 cache line을 할당하고 데이터가 쓰여지는 것이 LLC에 곧바로 수행되지만, DDIO를 위해서 할당한 LLC 영역의 10%를 넘는 순간 cache eviction이 발생하여 70ns가 증가하게 되는 것이다. 
• Figure 7(b)는 64B 단위로 테스트를 하였다. 여기서의 latency는 상대적으로 cache warm / cold의 비중이 줄어들어 70ns였던 차이가 10ns로 감소하였다.
• BW_RD의 경우에는 cache warm의 이점이 상당했다. (단, 그래프에 나타나지는 않았지만 512B단위에서는 다시 이 이점마저도 미미해졌다.) BW_WR의 경우에는 cache warm / cold의 여부에 따라 차이가 거의 없었다. 의심되는 요소로는 DDIO 영역이 빠르게 cleaning되어 모든 DMA Writes가 LLC에 쓰여지는 것으로 보임이 있다. DDIO를 비활성화 하거나 별도의 performance counter 등을 확인할 수 있는 방법이 없어 추정만 하였다고 한다.

 

6.4 NUMA Impact

• PCIe root complex와 Memory controller는 각 CPU Node에 속해있다. (CPU, DRAM, PCIe 모두 NUMA를 갖고 있다.) 따라서 PCIe가 memory에 접근하는 행위는 local 혹은 remote로 분류될 수 있다. 

• Figure 8은 Cache warm 상태에서 NUMA Local / Remote에 대한 DMA read bandwidth 성능 차이를 보여준다. ($1 - NUMA\ Remote\ bandwidth\ /\ NUMA\ Local\ bandwidth $) 64 Byte transfer의 경우 NUMA local 대비 NUMA remote가 약 20%의 성능 하락 (32 Gbps -> 25 Gbps)를 보인다. Transfer size가 클수록 성능 하락은 미미하고, 512 Byte 기준으로는 거의 없다고 볼 수 있다. 
• DMA write는 transfer size나 host buffer size에 크게 영향을 받지 않았다.
• Latency의 경우도 NUMA Remote에 전부 100ms가 추가된다는 점 말고는 동일했다.
• (Window Size가 16M를 넘길때는 다 증가한다. 논문에는 이유가 나와있지 않은 것 같긴하다. 추정컨대, window size가 LLC size (15MB)를 넘어가기 시작하면서 cache miss가 발생하기 시작했을 것이다. 이에 따라 local bandwidth와 remote bandwidth가 동시에 감소하면서 나눗셈의 결과 ($NUMA local bandwidith / NUMA remote bandwidth$)가 줄었을 것이라 추측한다.)

 

6.5 IOMMU 효과

• 마지막으로 IOMMU가 PCIe device와 host datapath 사이에 끼어든 케이스를 분석한다.
• Ivy Bridge의 IOMMU 구현 및 이보다 더 새로운 아키텍쳐에서는 TLB entry와 page table entry의 개수를 줄이기 위해서 super-page를 지원한다. 하지만 실험에서는 비활성화 하였고, 그에 따라 4KB page 단위로 patge table entry를 관리한다.

• Figure 9는 transfer size에 따라, widnow size에 따라 IOMMU 비활성화 대비 IOMMU 활성화 성능이 얼마나 감소하는지를 보여준다. ($1 - IOMMU 활성화 성능 / IOMMU 비활성화 성능$)
• window size가 작을 때는 transfer size에 따른 성능 차이가 없다. 
• 256KB를 넘어가는 순간 성능이 급격하게 감소한다. 64B DMA Read 기준으로 70%까지 감소하는 것을 볼 수 있다.
• 512B DMA Read는 성능이 감소하지 않았다.
• DMA Write는 이렇게 극단적이지는 않지만 여전히 감소하였다. 64B DMA Write 기준 55% 감소
• 재밌는 발견: 이를 통해서 IO-TLB의 entry 개수를 추산할 수 있었다. (256KB / 4KB = 64개) 이는 Intel이 공개한 적 없는 수치이다.
• Latency는 IOMMU를 활성화 시, 64B Read 기준 430ns에서 760ns로 늘어났다.
• IO-TLB에서 miss가 발생하면 page table walk으로 인하여 330ns가 추가된다. 
• 작은 transfer size에서는 이러한 부분이 latency와 bandwidth에 상대적으로 큰 영향을 끼친다. 
• 재밌는 발견: 인텔의 여러 세대에 대해서 이러한 경향이 동일했다. 결국, 인텔의 IOMMU는 첫 세대에서 많이 발전하지 않았음을 발견하였다.

 

7. 교훈과 사용사례

• 그동안 Linux 성능이나 CPU 성능 등을 자세하게 다루는 연구와 응용이 많이 제안되었으나, I/O 성능과 관련해서 (특히 pcie)는 거의 없었다.
• Table 2는 pcie-bench를 통해서 밝혀낸 관찰과 교훈을 정리하였다.
• IOMMU는 working set size가 커질수록 성능 감소가 심하게 나타난다. 따라서 TLB의 superpage를 활성화 하고, IO buffer를 소수의 super-page들에 뭉쳐놓는 것을 추천한다. 단, PCIe device를 여러 VM들에게 할당하는 환경에서는 여전히 어려울 것이긴 하다. (소수의 super-page에 뭉쳐놓는 것이 사실상 불가능하므로)
• NUMA 환경에서 작은 transfer size를 지닌 I/O를 수행하는 경우, NUMA-remote 접근의 비용이 높았다. 단, packet을 모두 NUMA local에 두는 것은 현실적이지 않기에, descriptor ring과 같은 자료구조들 만이라도 NUMA local에 두는 것을 추천한다.
• NUMA 환경에서 큰 transfer size를 지닌 I/O를 수행하는 경우에는 성능 차이가 많지는 않았다. 따라서 packet들을 처리되는 노드에 그대로 두는 것을 추천한다.
• DDIIO는 small transaction에 대하여 L3 cache에 있을 때 70ns가 더 빠른 결과를 보였다. 이는 descriptor ring을 접근하는 데 latency를 줄이는 방법으로, small packet의 경우 곧바로 L3에 씀으로써 성능 향상을 얻을 수 있을 것이다.

Section 7의 나머지 내용과 Section 8은 생락하였습니다.

9. Conclusion

• 해당 페이퍼는 PCIe root complex, device driver와 함께, PCIe가 host networking의 성능에 상당한 영향을 줄 수 있음을 보였다.
• 기존의 연구는 RDMA나 KVS 가속과 같은 특정 영역을 주로 다뤘지만, 우리의 pcie-bench는 PCIe protocol을 이해하는데 더 이론적인 모델과 방법론을 제안하였다. 
• PCIe-bench 외에도 다양한 하드웨어 (e.g., 여러 인텔 세대 하드웨어)와 다양한 시스템 설정 (e.g., DDIO, IOMMU, NUMA 등)으로부터 달라지는 특성들을 분석하였다. 
• 추후 연구로는 Intel 하드웨어 뿐만 아니라 AMD, ARM64, Power-based 아키텍쳐에서도 실험 및 분석을 해볼 수 있을 것이다. 나아가, 데이터 센터에서 일반적인 환경인 여러 PCIe device가 존재할 때의 성능도 추후 가능한 연구이다.