Embedded Port Operating System (EPOS)

1
Embedded Port Operating System (EPOS)

• Fred Kuhns
• (fredk_at_arl.wustl.edu, http//www.arl.wustl.edu/fr
  edk)
• Applied Research Laboratory
• Department of Computer Science and Engineering
• Washington University in St. Louis

2
The Big Picture
3
Simple Message Format
source address
node_id app_id
destination address
Source
Message Header
protocol params
node_id app_id
Destination
pr_id params
Protocol
application data
Message Body
application data
4
Advanced Services Router
Line Card
Control Processor
TI
RPP
ASP
Interconnection Network

• Line card (LC)
• Transmission interface (TI)
• Routine packet processing (RPP)
• Advanced services processing (ASP)
• Interconnection network interconnects ports and
  centralized control processor.
• Control Processor (CP) manages system

5
Embedded Port Processor
6
ASR Block Diagram
7
Example Processing
8
ASP Architecture

• Processing Engine (PE) contains a processing
  core, small amount of local memory and register
  files for multiple thread contexts
• Memory Interface (MI) provides access to
  external memory
• Control Interface (CI) Provides access to the
  external control bus.
• Management Processor (MP) Centralized manager
  for a given port.

9
Simplified Model of System
Processing Engine
Processing Engine
Thread Contexts
Local Memory
Thread Contexts
Local Memory
program text local data
program text local data


register file
register file
ALU
ALU
Bus Interface
Bus Interface
Bridge
Memory Module
Shared Memory
cache
MMU
Application Specific Data
Proc.
Input Queues
Output Queues
IPC
Local Memory
Management Processor
System Tables
10
Issues to Consider

• Application processing requirements
• IPC requirements
• scheduling and performance requirements
• resource requirements
• CPU job duration, periodicity, aperiodic,
  sporadic
• Memory must state be preserved across jobs, if
  so how much
• Models abstractions
• Protection and Security
• Computational model
• Threads versus FSM events versus algorithmic
• multiprogramming concurrent activities
• Secondary storage requirements
• Memory model
• sharing versus isolation
• dynamic or static allocations virtual memory
  relocatable

11
Overview

• Event driven model
• 1st class events Packet arrival, timer expire,
  message arrival
• Events are periodic, sporadic or aperiodic
• New Jobs must undergo admissions test
• Hierarchical scheduling Logical CPUs allocated
  to application, then app (or sched library)
  allocates jobs to CPUs
• Must bound overall delay and provide throughput
  guarantee for periodic and sporadic. Aperiodic is
  best-effort.
• Preemptive CPU scheduling
• Isolation between applications (app processes)
• shared global resources within task
• threads flow related sequence of jobs
• Support per thread memory allocation with
  protection
• Virtual memory (segmented, paged).
• CPU Local memory used as cache for resident sets.

12
Overview

• Protection and Security
• packet/flow authentication/authorization
• support IPv6 mechanisms in OS?
• Performance/Efficiency requirements
• Job duration generally short (usecs) would imply
  deferred preemptive model
• CPU allocation to app may be on larger time
  scale, preemptive scheduling
• Context switch between jobs must be cheap
• Can HW help?

13
Help from HW

• Programmable clock interrupts, but good if OS is
  not dependent on short period interrupts
• bind job with event queue and a SW controlled
  Released flag
• lightweight threads Explore

14
Solutions?

• Application creates threads
• user threads may be bound to kernel threads and
  input queues
• kernel threads may be used for running system
  activities
• real-time scheduling, MP support
• CPU threads are schedulable entities
• Memory
• access protection but permit explicit sharing
• assume dynamic installation and removal of
  programs
• local memory mapped to tasks address space
• global memory (slow) also mapped to address space
  (same vm address range for all tasks?)

15
What you will do first

• Design and implement a user space threading
  library
• Scheduling framework supports multiple scheduling
  policies
• Priority-driven, preemptive versions of FIFO,
  Round Robin
• extensible to support other work conserving and
  non-work conserving algorithms
• Interface must include the follwoing
• wth_exit(...), wth_create(...), wth_this(),
  wth_yield() and wth_join().