| Table of Contents |
|---|
System Architecture Diagram
OVSDriver Module
The OVSDriver module is the main component of the project and has several submodules:
- bh.c: "Bottom-halves" - queue of requests from upcall threads to the main thread.
- fwd.c: Implements the Indigo forwarding interface.
- kflow.c: Manages kernel flows (installation, invalidation, expiration).
- ovs_driver.c: Initialization/cleanup.
- translate_actions.c: Translation from OpenFlow matches and actions to openvswitch actions.
- upcall.c: Handles upcalls from the openvswitch module.
- vport.c: Implements the Indigo port manager interface.
The ovs_driver_int.h file defines the internal interfaces between these submodules.
Upcall Processing
"Upcalls" are messages from the openvswitch kernel module to userspace sent when the kernel does not have an exact-match flow for a packet. The main function of IVS is to handle these upcalls efficiently.
The IVS daemon spawns several threads (default 4) to handle upcalls. Each thread is assigned a set of ports. One Netlink socket is used per port for isolation. An upcall thread spins forever around epoll_wait(), waiting for new messages from its assigned ports.
When an upcall thread is woken from epoll_wait() it will read messages from the kernel in large batches to reduce the number of user/kernel transitions. For each message, it dispatches to the relevant handler depending on the type of upcall. For now we'll assume the upcalls are "misses", meaning there was no matching flow in the kernel flowtable.
When handling a miss, the upcall thread uses the flow key sent by the kernel to do a lookup in the userspace flowtable. If no flow was found the thread uses the BH queue to request a packet-in. Otherwise, it translates the OpenFlow actions into openvswitch datapath actions and sends the packet up to the datapath with an "execute" message.
...
System Architecture Diagram
