[dpdk-dev] Unable to redirect packets into kernel using dtap/dtun

[Stephen Hemminger]

On Fri, 2 Aug 2019 12:45:55 +0530
Nilesh <nileshunhale at cse.iitb.ac.in> wrote:

> Hello,
> 
> We are building an application where a majority of the packets on the 
> fast path are handled by DPDK, but a small subset of packets on the slow 
> path need to be redirected to a legacy userspace socket program that 
> runs over the kernel TCP/IP stack. Therefore, we are trying to inject 
> the slow path packets received by DPDK into the kernel via TUN/TAP device.
> 
> We have done the following: we created a tun device, assigned it an IP 
> address, and bound the legacy socket program to this address. The DPDK 
> program reads all packets from the NIC and writes the slow path packets 
> into this tun device. These packets are then successfully received by 
> the legacy socket program. However, we are unable to get this to work 
> with DPDK's tun/tap devices (dtun/dtap).
> 
> When we use dtap then packet is received in dtap0 (can be seen in 
> wireshark) but not reached the socket program.
> When we use dtun then packet is received in dtun0 (rx value increases 
> but is not captured by wireshark) and not reached the socket program.
> (We enabled ip_forwarding and disabled rp_filter for both "all" and 
> "dtun0" iface)
> (Reference:https://doc.dpdk.org/guides/nics/tap.html) 
> <https://doc.dpdk.org/guides/nics/tap.html>
> 
> Any pointers regarding how to do this using dtun/dtap will be helpful.
> Are we missing anything due to which linux tun device is working but 
> dtun/dtap isn't?
> 
> System specification :
> 2 machines with
> Distributor ID:    Ubuntu
> Description:    Ubuntu 18.04.2 LTS
> Release:    18.04
> Codename:    bionic
> 
> Kernel: 4.15.0-55-generic
> *DPDK* version: 19.05.0
> 
> Hardware:
> CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
> NIC 1: Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ (i40e)
> 
> (If any extra setup configuration information required will be provided)
> 

Make sure tap device in kernel is up?

You might try virtio as faster exception path.
https://doc.dpdk.org/guides-18.08/howto/virtio_user_as_exceptional_path.html