Communicating Data between Measurement LKMs and User Processes

Irrespective of the particular type of measurement performed by a set of source and

destination modules, the LKMs need to deploy additional mechanisms to communicate the necessary information from and to other components of the infrastructure at runtime.

For the purposes of this prototype implementation, two types of information are exchanged between the measurement modules and higher-level (user-space) processes. Source modules obtain configuration parameters mainly during initialisation but also at runtime, and

destination modules make the necessary per-packet data available for further measurement and analysis processes.

As it has been already discussed, loading of a source LKM initiates the in-line measurement activity and designates the instrumented node as the starting point of the measurement- enabled path. The LKM is able to potentially process every single outgoing IPv6 packet, but

the decision of which traffic is actually instrumented with the in-line measurement destination options is based on node-local policies passed as parameters to the module. A user-space process that can run either locally or remotely such as the test scheduler described in section 4.2, links the source LKM to the running Linux kernel and configures the measurement granularity by filling the entries of a control structure which is then passed to the module and specifies the filtering and sampling parameters of the measurement process (discussed in section 4.4.3.6). These configuration parameters can also be altered during the module’s operation without the need to remove and then reload the LKM.

On the other hand, a destination LKM, when loaded, implicitly specifies the end of the instrumented path that originates at the node running the corresponding source module. The LKM which examines every incoming IPv6 datagram is loaded without any parameters being explicitly specified since its measurement activity is triggered by the presence of the appropriate options within a datagram (hence, only appropriately-instrumented packets are actually being processed). However, when a packet is indeed eligible to be processed by the destination LKM and its measurement-related header data is eventually extracted and stored to the module’s FIFO structure, there needs to be a mechanism for this data to be exported to user-space processes that will “consume” the measurement indicators to implement different performance metrics and produce more aggregate results.

In short, source LKMs need to receive input from user-space whereas destination LKMs need to pass their output to user-space processes, in real time. These I/O operations have been realised by coupling a virtual character device with each measurement module and implementing the corresponding read and/or write driver routines. Every LKM, upon initialisation, registers itself with a character device file which has been created in advance145_. In order for multiple modules to simultaneously operate on the same system, an equal number of distinct character device files are created to accommodate input and output data for each module. Each module then implements the main functions to open, release, read from and write to the virtual device, as necessary, when they are called from a user-space process. The standard roles of read and write are reversed in the kernel, and therefore read functions are used for output from the module (and the character device) whereas write functions are used for input to the module [SaPo03].

Each source LKM implements a function which, when called from a user process, it overwrites (through the character device file) the entries of the module’s control structure, and consequently, it alters the granularity of the measurement process. A user-space application can hence specify different filtering and sampling parameters on demand to take

145 _{This is the most convenient way in order for the modules as well as the applications to know which}

immediate effect while the module is loaded, and then copy them from the user data segment to the kernel data segment, using the appropriate Input Output ConTroL (IOCTL) call146_. Accordingly, each destination LKM running at the other end of an instrumented path, implements a function called when a user process attempts to read from the character device file registered by the module. This function copies to the caller’s (process) buffer the bytes that correspond to the first (oldest) element of the FIFO queue holding the measurement- related header data of each processed incoming IPv6 packet. It subsequently frees the space occupied by this element in the memory-resident queue. This queue maintained by each destination module has a fixed maximum number of bytes that it can accommodate and when its capacity is reached, measurement data from subsequent packets is dropped. It hence becomes evident that especially for certain types of measurement (such as e.g. packet loss), a user-space process need to issue read calls to the corresponding character device file at a rate which can accommodate the rate of instrumented packets arriving at the destination LKM. The measurement granularity dictated by the corresponding source LKM can also influence the rate of arrival of instrumented packets at the destination node/module.

However, discussion on such rate synchronisation issues between the measurement modules and the higher-level applications is outside the scope of this thesis147_.

4.4.3.6

Measurement Scope, Granularity and Cost Reduction: Partial Byte