Use Cases
RISER: RISC-V for cloud services
RISER uses applications from three important domains that stress the need for harnessing the cloud: acceleration of memory-intensive operations in cloud workloads, networked object storage, and containerized execution. Evaluation will be based on microbenchmarks, possibly with platform-specific extensions, as well as standard cloud benchmarking suites.
Use Case 1: Acceleration of memory-intensive computation in cloud workloads
The PCIe Accelerator platform will support a use case focusing on efficient offload of memory intensive operations in cloud workloads. Examples include data compression / decompression, media file processing, analytical processing and reductions of large datasets, as well as ML / AI processing for model training and inference. The directives-driven OpenMP programming model (v.5) of explicitly defined multi-threaded, shared memory parallelism will be adopted. Parallelism is expressed via compiler directives. The accelerator platform will be used via OpenMP’s target offload, teams and spread constructs. OpenMP introduces parallelism by launching a set of threads, at the host side, that execute portions of the code concurrently. The OpenMP target directive instructs the compiler to generate a target task, i.e. map variables to an accelerator’s data environment and to execute the specified block of code on that device. Moreover, the teams directive introduces an additional level of parallelism by creating multiple teams of threads and distributing loop iterations across them.
Therefore, RISER will provide a demonstration of hierarchical parallelism, utilizing both host-side and accelerator-side execution resources. Multi-device support of accelerators (PCIe cards) will be demonstrated using the spread directive, which allows distributing a target task associated with a parallel loop over different devices.
Use Case 2: Networked object and key-value storage
The microserver platform will support a use case focusing on networked key/value stores and object stores for fast data ingest and retrieval. To simplify deployment and utilization in user-specified application workflows, the API to be provided will be compatible with the APIs of the Kubernetes runtime and of Amazon S3 object storage service, thus facilitating deployment in public, private and hybrid (private + public) cloud environments. The object and key-value store will provide a single global namespace and a consistent object storage interface accessible from multiple cloud providers, including hosted, on-premise, and edge infrastructure. The MinIO30 object store is one of the alternatives options to be used as storage backend, enabling applications to store and retrieve data objects of any size and format. Another alternative is the memcached memory object caching system.
This use case will also demonstrate hosting a key-value store (such as Kreon). Key-value stores are often deployed to enable in-memory caching of variable-length data, as a means to speed up applications by minimizing reads and writes to persistent storage systems.
Use Case 3: Containerized Execution
This task will develop and validate a use case for RISER’s microserver platform, focusing on containerized execution of user-developed microservices encapsulated within Linux containers. Moreover, this task will provide a port of the Kubernetes container orchestration engine for automating deployment, scaling, and management of containerized applications. Building on Use Case 2, this use case will demonstrate the combination of Kubernetes-managed computing infrastructure with networked object storage. Moreover, this task will provide a serverless runtime environment based on Kubernetes-managed containers. Serverless computing is an execution model where the cloud provider is responsible for executing a piece of code, typically expressed as a function, by dynamically allocating the necessary resources (i.e. server cores and memory, together with storage and networking resources).
This code is typically run inside stateless containers that can be triggered by a combination of event-driven conditions (e.g. network requests, filesystem and database activity) and time-driven service activations.
