tutorial codes interactions
CODES is a big project. There's lots of moving pieces and truly understanding all of it requires a lot of effort. The most important thing to keep in mind is that CODES is built up on top of ROSS. If you're unfamiliar with what that implies, I recommend you read the PDES tutorial first.
CODES simulations typically have three types of LPs: workload LPs, terminal LPs, and router/switch LPs. Any interaction between two LPs necessitates an "event" in the simulation. Because of this, the behavior of one LP during the simulation is entirely dependent on what other LPs send it events, and what type of events those are.
An overview of CODES can be seen below:
Workload LPs, which generate traffic for the simulated network to facilitate, are mapped to specific terminals in the simulated network. The workload LPs are defined based on a workload file which is the main simulation entry point. This file itself is essentially a ROSS simulation but CODES provides mechanisms for these self-contained workload LPs to interface with the simulated network. This interface is referred to as the model-net layer.
Put simply, a workload LP (let's call it X) might decide, "At time T, I'd like to send a message of size B bytes to another workload LP Y". It will call a specific function which breaks that message up into packet requests for the specific mapped terminal to inject into the network. So if the configured packet size of the network is 1024B and the message size, B, is 10240B then the model-net interface will queue up 10 packet requests for the network to facilitate. When a packet request is received by a terminal, it will inject it into the network of simulated switches and network will route the packet accordingly to the specific terminal which is mapped to the destination workload LP, Y. Once all 10 of the packets have arrived at the destination terminal, the terminal LP will communicate through the model-net interface to workload LP Y that a completed message has arrived.
Workload LPs are essentially pure ROSS LPs. Any communication between them can be easily done through standard ROSS events created and sent by each workload LP directly to each other. While this is often useful, this does not create traffic for simulation by the network. To do that, the workload LPs must interact with the model-net interface, giving it the information that it would like transmitted over the simulated network. The main mechanism for doing this is calling a model-net-event() method. This tells the model-net layer exactly how much data it would like to transmit, to whom it should be delivered, and when (from "now") this should be attempted to be scheduled.
In the above figure, we see a very simplified view of the model-net layer. Computationally speaking, the model-net layer is entirely executed by the workload LP but is simply the mechanism to abstract away the complexities of interfacing with the simulated network. A model-net-event() call is created which leads to the model-net layer working to determine how it should handle the data.
By default, CODES will determine if the destination workload LP is attached to the same network terminal and if it is, will then immediately facilitate the transmission of that message without attempting to inject it into the network. This essentially means that intra-node traffic is not explicitly simulated the same way that inter-node traffic is. If the destination workload LP is on a different terminal than that of the origin workload LP, then the packet gets put into a scheduling queue.
The scheduler's job is simple: if it knows that the attached network terminal has availability to inject packets into the network, it will send a packet request to the terminal. If it doesn't know, it will wait for the terminal to notify when it is ready for more traffic. This notification is called an Idle Event and is created by the terminal LP to interact with the model-net interface.
On the network side, there is an implemented model-net interface method (fulfills model_net_method_recv_msg_event() in model_net_method array), which is called (by the model-net layer on behalf of the workload LP) which conveys all the information from the packet request necessary to route the packet to its destination. This implemented method, on Dragonfly-Dally for example, creates a T_GENERATE event to send to the terminal LP causing it to generate and inject the requested packet into the network. If the terminal LP knows that it has the capability to send more, it will interface with the model-net layer and request more packets by calling the Idle Event method: model_net_method_idle_event().
As the workload LPs finish creating traffic according to how their designed, the last packets will be routed through the simulated network and be received by their destination workload LPs. When ROSS detects that no more events in the simulation are being created, the simulation will end.