[dpdk-dev] KNI interface operational state UP issue

[Bruce Richardson]

On Fri, Jan 09, 2015 at 05:20:26PM -0800, Aziz Hajee wrote:
> I am using the dpdk1.6.0r1
> The rte_kni.lo is loaded:
> lsmod | grep kni
> rte_kni               279134  1
> 
> however, the ifconfig vEth0, and vEth1 does not show link up ?
> How do i get the operational state up for these interfaces.
> $ sudo tcpdump -i vEth0
> tcpdump: vEth0: That device is not up
> 
> ifconfig vEth0
> vEth0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:12 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:3388 (3.3 KB)  TX bytes:0 (0.0 B)
> 
>  ifconfig vEth1
> vEth1     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:60 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:10252 (10.2 KB)  TX bytes:0 (0.0 B)
> 
> These KNI interfaces are created as per dmeg below from the CREATE IOCTL.
> sudo ifconfig vEth0 192.168.0.11 netmask 255.255.0.0
> SIOCSIFFLAGS: Timer expired
> aziz at fast-1:~/stm15-0108/stm/dpdk/dpdk-1.6.0r1_ss/lib/librte_eal/linuxapp/kni$
> ifconfig vEth0
> vEth0     Link encap:Ethernet  HWaddr 90:e2:ba:5f:1a:64
>           inet addr:192.168.0.11  Bcast:192.168.255.255  Mask:255.255.0.0
>           BROADCAST MULTICAST  MTU:1500  Metric:1
>           RX packets:50 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:14488 (14.4 KB)  TX bytes:0 (0.0 B)
> 
> Trying to set the vEth0 up, looks like it is doing the callback in the dpdk
> to the corresponding PMD NIC interface, and not the vEth0 kernel interface.
> 
With KNI, the actual underlying NIC interface is still under the control of the
DPDK application. What happens is that any ethtool requests that go to the kernel
driver, get passed into the userspace DPDK application to make the actual changes
to the hardware port. Does DPDK itself report the port as being up?

/Bruce