libmemif for Golang is build on the top of the original, C-written
libmemif library using `cgo`. It is therefore necessary to have C-libmemif
-header files and the library itself installed in locations known
+header files, and the library itself installed in locations known
to the compiler.
For example, to install C-libmemif system-wide into the standard
```
$ git clone https://gerrit.fd.io/r/vpp
$ cd vpp/extras/libmemif
-$ ./bootstrap
-$ ./configure
-$ make install
+$ mkdir build
+$ cd build
+$ cmake ..
+$ sudo make install
```
### Build
**libmemif** was designed for a maximum possible performance. Packets
are sent and received in bulks, rather than one-by-one, using
`Memif.TxBurst(queueID, packets)` and `Memif.RxBurst(queueID, count)`,
-respectively. Memif connection can consists of multiple queues in both
+respectively. Memif connection can consist of multiple queues in both
directions. A queue is one-directional wait-free ring buffer.
It is the unit of parallelism for data transmission. The maximum possible
lock-free granularity is therefore one go routine for one queue.
*raw-data* is a basic example showing how to create a memif interface,
handle events through callbacks and perform Rx/Tx of raw data. Before
-handling an actual packets it is important to understand the skeleton
+handling an actual packet it is important to understand the skeleton
of libmemif-based applications.
Since VPP expects proper packet data, it is not very useful to connect
Stop an instance of *raw-data* with an interrupt signal (^C).
+#### Jumbo Frames Raw data (libmemif <-> libmemif)
+
+*jumbo-frames* is simple example how to send larger and larger jumbo
+packets with libmemif adapter. This is simple copy of *raw-data* but with
+sending larger packets, so for more information read its code and documentation.
+
#### ICMP Responder
*icmp-responder* is a simple example showing how to answer APR and ICMP