Philosophy about the Embeddable Routing Machine
ERM is an outgrowth of my encounters with many, many other network simulation tools over the past decades of dealing with them. It’s different from all of them - because how I think about the problems seems to be vastly different than how everyone else thinks about them. It doesn’t mean I’m right!
For starters I don’t see any reason why the simulation should differ from the implementation. While you can’t compile ERM down to verilog, it tries to use tools that do, and perhaps eventually will have a higher level language in it that will get you closer to “there”.
It is a simulator, first, and a real world engine, second, but hopefully the added shims to deal with simulated time won’t interfere with actually being useful as a real world engine.
ERM works from higher level mini-descriptive languages
- It uses code generators for code that needs to be fast and tight
- It uses code generators for code that needs to be 100% correct
- It uses code generators anywhere speed is not important but clarity is
- It is declaratively table driven and state machine based
ERM looks like hardware
- Massively parallel
- Uses concepts like splay, scatter, stagger
- Uses explicit state machines wherever possible
ERM takes advantage of hardware
The base ERM machine can be easily mapped directly onto multiple modern intel and arm cores. It has functional units that can’t - the cryto-er, hasher, and lookupr/popcountr facilities in particular - but those do map down to hardware quite well and in selective cases, software assistance.
It also uses high end features of modern processors - popcount being the most obvious of these but also bitreversal and extraction techniques only available in the latest generation of cpus. It also attempts (although in many cases it is a poor choice from a speed perspective) to use the vector unit - most of the point of doing so is merely to use the on-chip resource rather than the stack.
Also: a goodly portion of the design is focused on taking advantage of massive embeddable multicores - and the limitations thereof - the Adapteva Parallella being an initial target.
ERM is fast
I kind of hope it will be faster than anything that exists today for managing route tables and the like. But we’ll see.
- Hard(er) real time is a goal throughout
ERM is lightweight
- small, tight, heavily reused code throughout the core routines
- overlays dropping unused code
ERM is secure
At least, I hope it will be.
- Posix shared memory
- Conventional Unix three tier permissions model
- Permissions dropped when possible
ERM uses old coding techniques
- real registers
- abort, trap, signal
- Everything is a file
- Where another tool sufficies (rsync, ssh), we use that rather than reinvent the universe
- C, not C++ or anything more “modern”
ERM uses modern coding techniques
- librcu and BSP threads
- Lock free data structures
- Pure functions
- Generational Garbage collection
- tagged memory
- mmap rather rather than stdio
- message passing rather than stacks
- Linker magic to swap in and out critical sections
It is not a library
Code directly for ERM MUST be compiled specially in order to work at all.
Other code that merely accesses ERM can be written in anything so long as it follows a few simple rules for security and memory allocation.
ERM is an experiment
ERM is weird
ERM is a solo effort by an old fart
Get something that works!
- Develop alternate daemon infrastructure
Add a forwarding engine and “cake”
Note on other methods
Other routing daemons
is really first class in many ways. It only shows its age on a few points.
is the goto simulator for everyone, and unbelievably difficult to understand.
I’ve tried. I don’t want to deal with it.
Suffers greatly from the object orientation disease.
Other packet processing engines
All these seem to be a great way to heat data centers.
I’m evaluating P4.