The 3GD driver can be divided into the following:
- Driver - Low level driver running in kernel space:
- Sending interrupt events to NtService
- Having OS abstraction layer
- Performing PCI registration/deregistration
- Having MMAP support
- Maintaining host buffer memory pool
- NtService - Daemon running in user space
The NtService is the actual driver in 3GD where all adapter specific code is located. NtService runs as a daemon and both services the adapters and handles the communication with applications - via LibNTAPI. NtService can be configured via ntservice.ini.
- LibNTAPI - API library
The LibNTAPI is the application API library. It allows applications to communicate with NtService via the NT_* API. The library is not just a dummy API parser. It contains some NtService offload - especially in the traffic path. NtService delivers segments to LibNTAPI that will divide the segments into packets if the application uses the packet interface. Hence NtService and LibNTAPI are working very closely together.
- LibNTOS - OS abstraction
The LibNTOS is an OS abtraction library. It ensures that the OS specific functions needed, such as memory mapping, sockets and shared memory, work in the same way and can be accessed from NtService and LibNTAPI via a common API.
3GD operates with a term called streams. A stream is a data channel between the application and NtService via LibNTAPI. Applications need to define a stream for a specific purpose, e.g. statistics, and then use that stream to communicate with NtService to obtain statistics. There are 256 streams available in 3GD and multiple streams of the same type can be defined. Once a stream is terminated, either controlled or by a crash, NtService ensures cleanup and return the stream to the list of free streams.
3GD has the following stream types available:
- Statistics Stream - receives and/or resets statistical information
- Info Stream - queries various information types from the system, e.g. port, adapter, sensor info
- Configuration Stream - configures run-time changeable parameters, e.g. port speed
- Event Stream - listens for events, e.g. sensor alarms or link up/down events
- Network Stream - receives and/or transmits data:
- RX Network Stream - receives packets
- TX Network Stream - transmits packets
- File Network Stream - receives packets from a captured file
Host buffers are DMA memory shared between NtService and the adapters. This DMA memory is memory mapped (mmap) via LibNTAPI into applications so packet access can be performed zero-copy. Host buffers can be configured to various size and on different NUMA nodes via ntservice.ini. Packets are received by adapters but unless a filter has been configured via NTPL they will be discarded. NTPL is used to assign traffic from adapters into host buffers and the host buffers are then assigned to streams.
To start using the system, the low level driver must be loaded via /opt/napatech3/bin/ntload.sh. This loads the low level driver, which awaits commands from NtService. The low level driver only needs to be loaded once and should never be unloaded. Next NtService needs to be started via /opt/napatech3/bin/ntstart.sh. This starts the NtService daemon which parses ntservice.ini, initialize all adapters and await commands from applications via libNTAPI. If the static configuration needs to be changed, NtService needs to be stopped, the change made and NtService started again.