Manycore network interfaces for in-memory rack-scale computing

DaglisAlexandros,; NovakovićStanko,; BugnionEdouard,; FalsafiBabak,; GrotBoris,

doi:10.1145/2872887.2750415

Cited by 11 publications

(15 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…EMC/Isilon [24]) solutions to clients connected via a conventional network. AppliedMicro's X-Gene2 server SoC [40] and Oracle's Sonoma [41] integrate the RDMA controller directly on chip, HP Moonshot [30] combines low-power processors with RDMA NICs, and research proposals further argue for on-chip support for one-sided remote access primitives [18,47]. Building larger logical entities using such rack-scale memory pooling approaches instead of the cache-coherent NUMA approach comes at a lower cost and complexity.…”

Section: Architectural Building Blocksmentioning

confidence: 99%

“…A representative of such emerging tightly integrated solutions is Scale-Out NUMA (soNUMA) [18,47], which delivers remote memory access latency within a small factor over local memory access. soNUMA is an architecture and protocol that supports one-sided remote read and write operations, i.e., a strict subset of RDMA operations.…”

Section: The Impact Of Faster Remote Readsmentioning

confidence: 99%

“…ulation model [18] ( Table 1). While RackOut over RDMA already delivers substantial performance improvements over the traditional scale-out approach, soNUMA's faster remote memory access further highlights the potential of RackOut.…”

Section: The Impact Of Faster Remote Readsmentioning

confidence: 99%

“…We evaluate the benefits of RackOut as a function of server count, size of the RackOut unit, and read/write ratio for datasets following a power-law popularity distribution. For a Zipfian read-only distribution with α = 0.99, the model predicts that a RackOut deployment of 512 servers grouped into 16-server RackOut units increases throughput by 6× with RDMA and 8.6× with Scale-Out NUMA (soNUMA) [18,19,47] without violating SLO.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

The Case for RackOut

Novaković¹,

Daglis²,

Bugnion³

et al. 2016

Proceedings of the Seventh ACM Symposium on Cloud Computing

Self Cite

View full text Add to dashboard Cite

To provide low latency and high throughput guarantees, most large key-value stores keep the data in the memory of many servers. Despite the natural parallelism across lookups, the load imbalance, introduced by heavy skew in the popularity distribution of keys, limits performance. To avoid violating tail latency service-level objectives, systems tend to keep server utilization low and organize the data in micro-shards, which provides units of migration and replication for the purpose of load balancing. These techniques reduce the skew, but incur additional monitoring, data replication and consistency maintenance overheads.In this work, we introduce RackOut, a memory pooling technique that leverages the one-sided remote read primitive of emerging rack-scale systems to mitigate load imbalance while respecting service-level objectives. In RackOut, the data is aggregated at rack-scale granularity, with all of the participating servers in the rack jointly servicing all of the rack's micro-shards. We develop a queuing model to evaluate the impact of RackOut at the datacenter scale. In addition, we implement a RackOut proof-of-concept key-value store, evaluate it on two experimental platforms based on RDMA and Scale-Out NUMA, and use these results to validate the model. Our results show that RackOut can increase throughput up to 6× for RDMA and 8.6× for Scale-Out NUMA compared to a scale-out deployment, while respecting tight tail latency service-level objectives.

show abstract

Section: Architectural Building Blocksmentioning

confidence: 99%

Section: The Impact Of Faster Remote Readsmentioning

confidence: 99%

Section: The Impact Of Faster Remote Readsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

The Case for RackOut

Novaković¹,

Daglis²,

Bugnion³

et al. 2016

Proceedings of the Seventh ACM Symposium on Cloud Computing

Self Cite

View full text Add to dashboard Cite

show abstract

“…Latency and throughput become two key parameters to evaluate the performance of a network function. For example, rack scale computing requires a network latency as low as a small factor of DRAM latency [5].…”

Section: Introductionmentioning

confidence: 99%

Reconfigurable computing for network function virtualization: A protocol independent switch

Chen

Mishra

Zervas

2016

2016 International Conference on ReConFigurable Computing and FPGAs (ReConFig)

View full text Add to dashboard Cite

Abstract-Network function virtualization (NFV) aims to decouple software network applications from their hardware in order to reduce development and deployment costs for new services. To enable the deployment of diverse network services, a reconfigurable and high performance hardware platform can bring considerable benefits to NFV. In this paper, an FPGA-based platform is proposed to perform as a protocol reconfigurable NFV switch. Logic circuit of virtual network functions can be reconfigured at run time on the proposed platform. A reconfiguration process is also proposed to enable packet loss free switch-over between virtual network functions that delivers undisrupted service. The platform can be reconfigured between Layer 1 circuit switch and Layer 2 Ethernet packet switch. Once running as a packet switch, the platform can switch over from Layer 2 Ethernet switch to Layer 3 IP parser and even Layer 4 UDP parser. Performance of the implemented 2x2 switch at 10Gbps per port delivers a minimum latency of 300 nanoseconds (circuit switch) and maximum latency of 1 microsecond. Reconfiguration between IP and UDP parser without loss of data is also demonstrated.

show abstract

Flexible device compositions and dynamic resource sharing in PCIe interconnected clusters using Device Lending

et al. 2019

View full text Add to dashboard Cite

Modern workloads often exceed the processing and I/O capabilities provided by resource virtualization, requiring direct access to the physical hardware in order to reduce latency and computing overhead. For computers interconnected in a cluser, access to remote hardware resources often requires facilitation both in hardware and specialized drivers with virtualization support. This limits the availability of resources to specific devices and drivers that are supported by the virtualization technology being used, as well as what the interconnection technology supports. For PCI Express (PCIe) clusters, we have previously proposed Device Lending as a solution for enabling direct low latency access to remote devices. The method has extremely low computing overhead, and does not require any application- or device-specific distribution mechanisms. Any PCIe device, such as network cards disks, and GPUs, can easily be shared among the connected hosts. In this work, we have extended our solution with support for a virtual machine (VM) hypervisor. Physical remote devices can be “passed through” to VM guests, enabling direct access to physical resources while still retaining the flexibility of virtualization. Additionally, we have also implemented multi-device support, enabling shortest-path peer-to-peer transfers between remote devices residing in different hosts.Our experimental results prove that multiple remote devices can be used, achieving bandwidth and latency close to native PCIe, and without requiring any additional support in device drivers. I/O intensive workloads run seamlessly using both local and remote resources. With our added VM and multi-device support, Device Lending offers highly customizable configurations of remote devices that can be dynamically reassigned and shared to optimize resource utilization, thus enabling a flexible composable I/O infrastructure for VMs as well as bare-metal machines.

show abstract

Manycore network interfaces for in-memory rack-scale computing

Cited by 11 publications

References 29 publications

The Case for RackOut

The Case for RackOut

Reconfigurable computing for network function virtualization: A protocol independent switch

Flexible device compositions and dynamic resource sharing in PCIe interconnected clusters using Device Lending

Contact Info

Product

Resources

About