3.3 Module and Task Decomposition

This section will discuss design considerations with respect to partitioning the system into tasks and modules. It will then use the example of a Layer 2 Ethernet switch to illustrate the concepts. The assumption is that the system is a single-processor system running an RTOS. Systems with multiple boards and processors are discussed in Chapter 8.

The following list is a set of guidelines for organizing the modules and tasks in a communications system:

1. There are one or more drivers which need to handle the various physical ports on the system. Each driver can be implemented as a task or module. There are one or more Interrupt Service Routines (ISRs) for each driver.

2. The drivers interface with a higher layer demultiplexing/multiplexing task for reception and transmission of data. This is the single point of entry into the system for received frames. Similarly, this task is the only entity which interfaces to the driver for transmission.

3. Each protocol is designed as a module. It can be implemented as a task if it requires independent scheduling and handling of events, such as timers. If the overhead of context switching and message passing between the tasks is unacceptable, multiple protocol modules can run as one task.

4. Control and data plane functions, along with fast/slow path considerations will be used for grouping tasks and modules. Hardware acceleration will also play a part here.

5. Housekeeping and management plane functions like SNMP agents and Command Line Interface (CLI) will need to have their own task(s).

6. If memory protection is used, the interfaces between the tasks will be via messages. Otherwise, functional interfaces can be used. This will be discussed in greater detail in Section 3.6

The above guidelines are applied in the example of the Layer 2 switch, as discussed below.