EPIC-1: Setting up truly heterogeneous topology

[OmerMajNition]

Magnition customers need to have freedom to define complex topologies using Lingua Franca (LF) based on their practical use cases. This Epic has user stories that highlight scenarios where either LF doesn’t have support or the available features are too cumbersome to use in most practical scenarios.

Goal is to let users define any topology of their demand leveraging reusable LF reactor components. For this to happen we need to design reusable reactors that provide diverse capabilities when deployed and have the room for future feature additions. We would see through examples what we mean with a reusable reactor.

Building Block Reactors
Let’s consider the following reusable building block reactors

1. Cache
2. Load Balancer
3. DRAM
4. SSD

These above reactors form the basis of the next set of reactors built on top of these.

Cache reactor has allocation and eviction responsibilities. Users can add their own allocation strategies within Cache reactor, and they could add other eviction strategies implemented as part of cache reactor. This is truly a reusable as well as extendible reactor in terms of features.

Load Balancer is a multi-port input and multi-port output reactor that receives the traffic coming from input port routes to one of the output ports (this routing strategy is user defined). Responses from the routed traffic are sent back to the originator of the request. Load Balancer can be used as a proxy, serializer, deserializer depending upon the use case.

DRAM reactor emulates the behavior of DRAM memory. It has input ports for read and write requests, and output ports for responses to the requests.

SSD reactor emulates the behavior of SSD memory. It has input ports for read and write requests, and output ports for responses to the requests.

Both DRAM and SSD reactors have exactly the same input and output ports structure; the difference lies in the internal processing of requests within reactors.

Basic Server design using building blocks

Leveraging building blocks, let's design a very basic Server. It has 2 caches, L1 and L2, with DRAM as L1 cache storage medium and SSD as storage medium of L2 cache.

POP design using building blocks and Basic Server

This reusable POP reactor lets users configure the size of multi-banked servers. Traffic to these servers would be load balanced by a load balancer

Trivial Homogeneous Topology Example

Let’s consider a basic topology where the user wants to have 2 POPs in the system, having 2 servers within each POP.

Very much doable with current LF support available. Even if we want to setup each reactor in the topology as per user requirements we can pass an array parameter all the way down to leaf nodes and each reactor can read the configuration based on its index (linear combination to find the index within array)

Questions arise when users want to setup a heterogeneous topology to

1. Have different number of Servers within each POP
2. Be able to decide on the levels of cache and storage medium for each Cache in a Server
3. Configure each reactor of the heterogeneous topology as per practical use cases

Following user stories explain with examples how the topologies would look like and why we need to think through to arrive at a viable, flexible and scalable solution.

User Stories:

• User Story 1-1: Sizing of Reusable Child Reactors #63
• User Story 1-2: Individually Configuring nested Child Reactors #64
• User Story 1-3: Interchangeable child reactors and flexible wiring #65