1 / 19

Hermes: An Integrated CPU/GPU Microarchitecture for IPRouting

Hermes: An Integrated CPU/GPU Microarchitecture for IPRouting. Author : Yuhao Zhu , Yangdong Deng , Yubei Chen Publisher: DAC'11, June 5-10, 2011, San Diego, California, USA Presenter: Ye- Zhi Chen Date: 2011/10/5. Introduction.

alma
Download Presentation

Hermes: An Integrated CPU/GPU Microarchitecture for IPRouting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hermes: An Integrated CPU/GPU Microarchitecture for IPRouting Author: Yuhao Zhu , Yangdong Deng , Yubei Chen Publisher: DAC'11, June 5-10, 2011, San Diego, California, USA Presenter: Ye-Zhi Chen Date: 2011/10/5

  2. Introduction Current GPU architectures are still under two serious limitations for routing processing : • GPU computing requires the packets to be copied from CPU’s main memory to GPU’s global memory • the batch based GPU processing could not guarantee processing QoS for an individual packet (throughput vs delay) A novel solution:Hermes, an integrated CPU/GPU, shared memory microarchitecture that is enhanced with an adaptive warp issuing mechanism for IP packet processing

  3. Hermes Hermes: a heterogeneous microarchitecture with CPU and GPU integrated on a single chip memory .The copy overhead can thus be removed by sharing a common memory system between CPU and GPU

  4. Hermes The warp issuing mechanism problem • Warp – the basic unit of job scheduling on GPUs • The warp issuing mechanism of Hermes is responsible for assigning parallel tasks onto shader cores for further intra-core scheduling. • Best effort strategy – the number of warps that can be issued in one round is only constrained by the number of available warps as well as hardware resources such as per core register and shared memory size. • adaptive warp issuing mechanism – adapts to the arrival pattern of network packets and maintains a good balance between overall throughputand worst-case per-packet delay.

  5. Hermes • The packets are received by network interface cards (NICs) and then copied to the shared memory via DMA transfers. The CPU is thus able to keep track of the number of arrived packets. Accordingly, the CPU is responsible for notifying the GPU to fetch packets for processing • When CPU decides it is appropriate to report the availability of packets, it creates a new FIFO entry with its value as the number of packets ready for further processing, assuming the task FIFO is not full • the GPU is constantly monitoring the FIFO and making decisions on fetching a proper number of packets. • The minimum granularity , i.e., number of packets, of one round of fetching by GPU should be at least equal to the number of threads in one warp

  6. Hermes How frequently the CPU should update the task FIFO? • transferring a packet from NIC to the shared memory involves a book-keeping overhead • too frequently updating of the task FIFO also complicates GPU fetching due to the restriction of finest fetching granularity • too large an interval between two consecutive updates increases average packet delay

  7. Hermes Solution • set the minimum data transfer granularity to be the size of a warp, i.e., 32 packets (from NIC to shared memory) • if there are not enough packets arriving in a given interval, these packets should still be fetched and processed by GPU, interval is chosen to be 2 warp arriving times • A round-robin issuing strategy is employed to evenly distribute the workload among each shader core

  8. Hermes Guaranteed In-Order Warp Commit • Thread warps running on one shader core may finish in an arbitrary order,not to mention warps running on different shader cores • TCP - its header includes extra areas to enable retransmission and reassembly • UDP – it does require in-order processing

  9. Hermes Delay Commit Queue • The key idea is to allow out-of-order warps execution but enforce in-order commitment. • DCQ holds the IDs of those warpsthat have finished but not committed yet • Every time a warp isabout to be issued onto one shader core, and the DCQ is not full,a new entry is allocated. • Only could a warp be committedwhen all warps arrived earlier have been finished

  10. Hermes

  11. Hermes API modification • Memory copy API is not necessary • Add two memory management API : RMalloc and Rfree • Abandon thread blocks , directly organized threads in warps • packetIdx

  12. Experiment Configuration: • DPI : bloom filter • String rule set :Snort • Packet classification : linear search • CheckIPHeader, DecTTL, and Fragmentation:RouterBench

  13. Experiment Three QoS metrics: • Throughput:the total number of bits that can be processed and transferred during a given time period • Delay: 1.queuing delay:The waiting time which the packet arriving rate exceeds the processing throughput of the system, the succeeding packets have to wait before shader cores are available. 2.service delay:the time for a packet to receive complete processing by a shader core • Delay variance:The delay disparity of different packets measured by interquartile range

  14. Experiment

  15. Experiment

  16. Experiment

  17. Experiment

  18. Experiment

  19. Experiment

More Related