| Both sides previous revision Previous revision Next revision | Previous revision |
| summerofcode2018projects:extensionstonetmap [2018/08/03 13:44] – StefanoDuo | summerofcode2018projects:extensionstonetmap [2018/10/27 11:20] (current) – StefanoDuo |
|---|
| |
| ==== Per-buffer variable offsets ==== | ==== Per-buffer variable offsets ==== |
| It follows the same scheme of per-ring 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. | It follows the same idea of per-ring fixed buffer offsets and its stored inside the ''%%struct netmap_slot%%''. Because the ownership over the slots is well defined, this type of offset can be changed any time the kernel (or the userspace applications) owns the slot. |
| | |
| | Kernel side ''%%NMB()%%'' and ''%%PNMB()%%'' already receives the ''%%struct netmap_slot%%'' so we only need to the the offset field into account. Buffer overflow protection is accomplished through the offset parameter of ''%%NETMAP_BUF_SIZE()%%'', just like per-ring fixed offsets. |
| | |
| | From the userspace perspective this type of offset needs to be handled explicitly by the application. It cannot be handled transparently by the ''%%NETMAP_BUF()%%'' macro, because it doesn't receive a ''%%struct netmap_slot%%'' as one of its parameters, and the macro cannot be changed otherwise backwards compatibility cannot be obtained. Therefore problems could arise during zero-copy (or even while receiving slots from the kernel, if netmap starts using this type of offset itself). An option has been added to let the application specify that it won't handle per-slot variable offsets. Accordingly to this option the memory allocator gets flagged, so that every buffer from that allocator are used either by application aware of per-slot buffer offsets or by aware application. |
| |
| ==== Testing framework ==== | ==== Testing framework ==== |
| 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. | 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. It has been extended it with basic functionalities that can be used as building blocks for writing 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. | |
| | For more complex behavior multiple calls to functional.c are needed, and between those calls an interface may need to stay up, thus functional.c can start and stop a daemon. This daemon acts like a file descriptor server and can hold netmap interfaces file descriptors and lend them on request. |
| | |
| | Furthermore i wrote a bash library which eases and shortens the time required to write a test script. It provides wrappers around the most common operations executing during a test, reducing the amount of boilerplate code needed. The wrappers provided to create VALE persistent ports and VETH interfaces and attach/detach interfaces to VALE bridges automatically handle the cleanup after the test ends (implemented through traps). |
| | |
| | ===== Notes ===== |
| | |
| | ==== Per-ring fixed offset behavior ==== |
| | This type of offset is usually applied to the rings specified by the register request but there are some exceptions. |
| | * netmap pipes: the offset is applied to every ring of both ends of the pipe. This is needed because the exchange buffers through zero-copy. |
| | * netmap monitors: the offset cannot be specified by the application, but it is retrieved from the monitored rings. This is needed because having a different offset from the monitored rings might cause a packet to require more slots inside the monitor ring. |
| |
| ===== Deliverables ===== | ===== Deliverables ===== |
| * Extend netmap to support per-buffer offsets. ✔ | * Extend netmap to support per-buffer offsets. ✔ |
| * August 6th: End of coding (soft) | * August 6th: End of coding (soft) |
| * Clean up code and documentation. | * Clean up code and documentation. ✔ |
| * August 14th: End of coding (hard) | * August 14th: End of coding (hard) |
| |
| https://svnweb.freebsd.org/socsvn/soc2018/sduo/ | https://svnweb.freebsd.org/socsvn/soc2018/sduo/ |
| |
| ===== Notes ===== | ===== Future Contributions ===== |
| | Update netmap specific NIC drivers to be offset aware, as they currently do not support any type of offset. |
| Nothing at the moment. | |
| |
| ===== Useful links ===== | ===== Useful Links ===== |
| |
| * [[http://info.iet.unipi.it/~luigi/netmap/|netmap]]. | * [[http://info.iet.unipi.it/~luigi/netmap/|netmap]]. |
| * [[http://info.iet.unipi.it/~luigi/vale/|VALE]]. | * [[http://info.iet.unipi.it/~luigi/vale/|VALE]]. |
| |