Extensions to the netmap framework

This is an old revision of the document!

Student: Stefano Duo (duostefano93@gmail.com)
Mentors:
- Giuseppe Lettieri (g.lettieri@iet.unipi.it)
- Vincenzo Maffione (v.maffione@gmail.com)

Project description

The project aims to:

Write a kernel module to extend VALE switches to support the IEEE 802.1Q standard (vlans).
Develop a testing framework for netmap.
Extend netmap to support buffer offsets.

Write a char device driver which upon receiving a configuration, through a write() system call, will create a VALE switch with modified forwarding logic (through the API that netmap exposes to kernel modules) to handle vlan tags inside Ethernet headers. More precisely, given that VALE can't multicast frames, we need to create a non modified switch for every existing vlan in the configuration and a single switch with modified forwarding logic. The modified switch upon receiving a frame will act differently based on the receiving interface:

if the interface isn't the trunk port then it tags the frame with the vlan id represented by the switch connected to its other end and forwards it to the trunk port (if one exists).
if the interface is the trunk port then it reads the vlan id, untags the frame and forwards it to the interface which has its other end connected to the switch representing that vlan id (if one exists).

Given the fixed nature of this type of offsets, the approach I would like to take, and that has been suggested by the netmap team, is to let netmap internally handle the offset math, thus giving directly the “real” buffer starting address, and then let the user “go backwards” if he or she wants to use the offset space.

From the userland perspective a buffer is obtained through the NETMAP_BUF() macro (defined in netmap_user.h), which receives a struct netmap_ring and the index of the requested buffer. Therefore we must create a new field inside the struct netmap_ring to store the offset for that ring and, to maintain the kernel-userland ABI, resize the sem field, which is basically a placeholder for new fields; this way NETMAP_BUF() can be modified to handle the offset internally.

From the kernel perspective a buffer logical (and physical) address is obtained through NMB() and PNMB() (defined in netmap_kern.h). They receive a struct netmap_adapter and a few other things. They will need to be modified to receive the struct netmap_kring which contains the buffer instead of the adapter (it can be retrieved from the kring). A new field to store the offset value need to be added to the struct netmap_kring as well. Finally a new option must be created to let the user specify if he or she wants to open an interface with offsets.

It follows the same scheme of per-adapter fixed buffer offsets, but now the various functions need a way to retrieve the struct netmap_slot of the buffer, probably by passing it as an additional argument.

functional.c (from the netmap repository) is a CLI tool already capable of sending and receiving UDP packets with specified length and a few of other possible options. The general idea is to extend it with basic functionalities that can be used as building blocks for building tests, e.g. send/expect packet with a specific payload and/or a specific MAC address, etc. For more complex behaviour multiple calls to functional.c might be needed, and between those calls an interface may need to stay up, thus functional.c should have another process acting as a daemon which holds netmap interfaces file descriptors and lends them on request.

Implement an external kernel module which extends VALE switches to support virtual lans (IEEE 802.1Q standard) and a CLI tool to easily manage vlan configurations.
Implement the testing framework as a CLI tool with a set of basic functionalities which will be used to write a suite of tests for netmap.
Extend netmap to support per-adapter buffer offsets and make use of the inside the vlan external module; then add support for per-buffer offsets.

May 14th: Start of coding
- Write a kernel module which implements an hardcoded vlan configuration.
May 21st: Week 2
- Allow configurations to be managed through system calls instead of being hardcoded.
May 28th: Week 3
- Write a CLI tool to manage configurations.
June 4th: Week 4
- Bug fixing and documentation.
June 11th - June 15th: Mid-term Evaluations #1
June 18th: Week 6
- Extend functional.c to manage file descriptors of interfaces.
June 25th: Week 7
- Extend functional.c with functionalities needed to compose tests.
July 2nd: Week 8
- Write a suite of tests through the new framework.
July 9th - July 13th: Mid-term Evaluations #2
July 9th: Week 9
- Extend netmap to support per-adapter buffer offsets.
July 16th: Week 10
- Extend the VALE vlan kernel module to make use of buffer offsets.
July 23rd: Week 11
- Extend netmap to support per-buffer offsets.
August 6th: End of coding (soft)
- Clean up code and documentation.
August 14th: End of coding (hard)