[dpdk-users] OVS-DPDK - TAP0 - vdev (af_packet) device is linkdown

[Stephen Hemminger]

On Tue, 20 Jun 2017 09:40:47 +0000
"Avi Cohen (A)" <avi.cohen at huawei.com> wrote:

> Hello All,
> 
> I did upgrade to dpdk-17.05 and ovs-2-7.1 and create a vdev - af_packet device according the config script below 
> This tap device connects the ovs-dpdk to a name space
> The problem is that this tap00 device is linkdown - (never reach  RUNNING state )  - hence no pkt is received transmitted on this interface  although the tap0 creation in ovs is OK, 
> I'm attaching  the config script and output of netstat and ifconfig in the namespace
> Can someone please tell me how to activate the tap0 ?
> 
> Config script :
> 
> 
> cd ../dpdk-17.05/usertools/
> modprobe uio
> insmod ../x86_64-native-linuxapp-gcc/kmod/igb_uio.ko
> ifconfig ens3 down
> 
> ./dpdk-devbind.py --bind=igb_uio 0000:00:03.0 ./dpdk-devbind.py --status
> 
> cd -
> 
> pkill -9 ovs
> rm -rf /usr/local/var/run/openvswitch
> rm -rf /usr/local/etc/openvswitch/
> rm -f /usr/local/etc/openvswitch/conf.db
> mkdir -p /usr/local/etc/openvswitch
> mkdir -p /usr/local/var/run/openvswitch
> 
> 
> ./ovsdb/ovsdb-tool create /usr/local/etc/openvswitch/conf.db ./vswitchd/vswitch.ovsschema ./ovsdb/ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach ./utilities/ovs-vsctl --no-wait init
> 
> echo 8192 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
> echo 8192 > /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages 
> 
> mkdir -p /mnt/huge
> mkdir -p /mnt/huge_2mb
> mount -t hugetlbfs none /mnt/huge_2mb -o pagesize=2MB
> 
> modprobe openvswitch
> export DB_SOCK=/usr/local/var/run/openvswitch/db.sock
> 
> ./utilities/ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true ./vswitchd/ovs-vswitchd unix:$DB_SOCK --pidfile --detach ./utilities/ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x80
> 
> 
> 
> utilities/ovs-vsctl --may-exist add-br br-int \
>   -- set Bridge br-int datapath_type=netdev \
>   -- br-set-external-id br-int bridge-id br-int \
>   -- set bridge br-int fail-mode=standalone 
> 
> 
> 
> ip tuntap add dev tap0 mode tap
> 
> ovs-vsctl add-port br-int tap0 -- set Interface tap0 type=dpdk \
>     options:dpdk-devargs=eth_af_packet0,iface=tap0 
> 
> 
> 
> ip netns add red
> ip link set tap0 netns red
> ip netns exec red ip addr add 1.1.1.20/24 dev tap0 ip netns exec red ip link set tap0 up
> 
> 
> 
> 
> utilities/ovs-vsctl --may-exist add-port br-int vxlan0 \
>   -- set interface vxlan0 type=vxlan options:remote_ip=172.31.100.44 options:key=1000 
> 
> 
> 
> 
> utilities/ovs-vsctl --may-exist add-br br-phy \
>     -- set Bridge br-phy datapath_type=netdev \
>     -- br-set-external-id br-phy bridge-id br-phy \
>     -- set bridge br-phy fail-mode=standalone \
>        other_config:hwaddr=02:d7:d1:26:84:e5  
> 
> 
> utilities/ovs-vsctl --timeout 10 --may-exist add-port br-phy dpdk0 -- set Interface dpdk0 type=dpdk options:dpdk-devargs=0000:00:03.0 
> 
> 
> 
> 
> ip addr add 172.31.100.80/24 dev br-phy
> 
> 
> 
> ip link set br-phy up
> ip link set br-int up
> iptables -F
> 
> 
> utilities/ovs-appctl ovs/route/show
> 
> 
> ip netns exec red bash
> ifconfig lo up
> 
> #################################
> netstat -v -s -e
> Ip:
>     7 total packets received
>     0 forwarded
>     0 incoming packets discarded
>     7 incoming packets delivered
>     14 requests sent out
> Icmp:
>     7 ICMP messages received
>     0 input ICMP message failed.
>     ICMP input histogram:
>         destination unreachable: 7
>     14 ICMP messages sent
>     0 ICMP messages failed
>     ICMP output histogram:
>         destination unreachable: 7
>         echo request: 7
> IcmpMsg:
>         InType3: 7
>         OutType3: 7
>         OutType8: 7
> Tcp:
>     0 active connections openings
>     0 passive connection openings
>     0 failed connection attempts
>     0 connection resets received
>     0 connections established
>     0 segments received
>     0 segments send out
>     0 segments retransmited
>     0 bad segments received.
>     0 resets sent
> Udp:
>     0 packets received
>     0 packets to unknown port received.
>     0 packet receive errors
>     0 packets sent
> UdpLite:
> TcpExt:
>     0 packet headers predicted
> IpExt:
>     InOctets: 784
>     OutOctets: 1372
>     InNoECTPkts: 7
> root at ip-172-31-100-80:/home/ubuntu/openvswitch-2.7.0# ifconfig
> lo        Link encap:Local Loopback  
>           inet addr:127.0.0.1  Mask:255.0.0.0
>           inet6 addr: ::1/128 Scope:Host
>           UP LOOPBACK RUNNING  MTU:65536  Metric:1
>           RX packets:7 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1 
>           RX bytes:784 (784.0 B)  TX bytes:784 (784.0 B)
> 
> tap0      Link encap:Ethernet  HWaddr 1a:ef:3c:87:d7:67  
>           inet addr:1.1.1.20  Bcast:0.0.0.0  Mask:255.255.255.0
>           UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
>           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000 
>           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> 
> Best Regards
> 
> avi

If you are using one of the kernel access methods (like tap) for your
primary datapath, there is no benefit from DPDK. Aren't you better off
with non-DPDK version of Openvswitch? DPDK is not a secret go fast sauce.

Standard OpenVswitch

     NIC  ---> Kernel : OVS  ---> |  --> Guest

DPDK OVS (with TAP)
 
     NIC ---> OVS DPDK  ---> (tap) --> Kernel --> | --> Guest

The additional over head of kernel/user copy and system call makes any
benefit of DPDK disappear.