> Last argument specifies interrupt function to use. This function only responds to ARP requests. This is important because, packet generation and transmitting is handled by a separate thread. Calling memif_tx_burst from multiple threads writing on same queue could transmit uninitialized buffers.
Once connection is established, you can send ping from VPP to icmpr-epoll app to learn its mac address.
```
DBGvpp# ping 192.168.1.2
```
> There should be no ICMP response. Only ARP response.
Now send ICMP requests from icmpr-epoll:
```
send <index><num-of-packets><ip_daddr><hw_daddr>
send 0 5 192.168.1.1 02:fe:ff:ff:ff:ff
```
this command will create new thread which will generate icmp packets and transmit them over memif connection with specified index. Once the sequence is finished status will be printed.
###### Example results (owerview of test data)
(This test was run with modofication in VPP-memif plugin. The modification disallows memif tx node to allocate last ring buffer)
lib-tx: 200M (if ring full don't drop packets)
vpp-rx: 200M
vpp-tx: 200M - 50K (if ring full drop packets)
lib-rx: =vpp-tx
drop: ~0.025% (full ring)
pps: ~650K
multiple interfaces:
pps: divided
drop: constant
#### TC2: LIB-LIB
This test case will not drop packets if memif ring is full. Instead it will loop until all required packets have been sent.
Start two instances of icmpr-epoll example app.
instance 1:
```
conn 0 1 0
```
instance 2:
```
conn 0 0 1
send 0 5 192.168.1.1 aa:aa:aa:aa:aa:aa
```
> icmpr-epoll example app doesn't check ip or mac address so as long as the format is correct you can type anything as ip_daddr and hw_daddr arguments.