Here are the steps to reproduce the issue:

1. Create one Virtual Function (VF) on a physical interface that supports
SR-IOV (in my case it's an Intel i350 interface):
$ echo 1 > /sys/class/net/eth10/device/sriov_numvfs

2. Lookup its PCI address, for example with
$ --status-dev net
0000:05:10.3 'I350 Ethernet Controller Virtual Function 1520' if=eth11
drv=igbvf unused=igb_uio,vfio-pci,uio_pci_generic

3. Bind the VF to a DPDK-compatible driver. I'll use vfio-pci, but igb_uio
too will reproduce the issue:
$ --bind=vfio-pci 0000:05:10.3

4. Create an OVS bridge and set its datapath type to netdev:
$ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev

5. Add the VF to the bridge as a DPDK interface:
$ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk

6. Now ovs-vswitchd.log reports that OVS repeatedly crashes (segmentation
fault) and restarts itself, in a loop:
2018-01-11T09:28:28.338Z|00139|dpdk|INFO|EAL: PCI device 0000:05:10.3 on
NUMA socket 0
2018-01-11T09:28:28.338Z|00140|dpdk|INFO|EAL:   probe driver: 8086:1520
2018-01-11T09:28:28.338Z|00141|dpdk|INFO|EAL:   using IOMMU type 1 (Type 1)
2018-01-11T09:28:28.560Z|00142|dpdk|INFO|PMD: eth_igbvf_dev_init():     VF
MAC address not assigned by Host PF
2018-01-11T09:28:28.560Z|00143|dpdk|INFO|PMD: eth_igbvf_dev_init():
Assign randomly generated MAC address c6:13:67:7b:31:6b
2018-01-11T09:28:28.560Z|00144|netdev_dpdk|INFO|Device '0000:05:10.3'
attached to DPDK
2018-01-11T09:28:28.563Z|00145|dpif_netdev|INFO|PMD thread on numa_id: 0,
core id:  3 created.
2018-01-11T09:28:28.566Z|00146|dpif_netdev|INFO|PMD thread on numa_id: 0,
core id:  2 created.
2018-01-11T09:28:28.566Z|00147|dpif_netdev|INFO|There are 2 pmd threads on
numa node 0
2018-01-11T09:28:28.646Z|00148|dpdk|INFO|PMD: igbvf_dev_configure(): VF
can't disable HW CRC Strip
2018-01-11T09:28:28.646Z|00149|netdev_dpdk|ERR|Interface dpdk-p0 MTU (1500)
setup error: Operation not supported
2018-01-11T09:28:28.646Z|00150|netdev_dpdk|ERR|Interface dpdk-p0(rxq:1
txq:1) configure error: Operation not supported
2018-01-11T09:28:29.062Z|00002|daemon_unix(monitor)|ERR|1 crashes: pid 2494
died, killed (Segmentation fault), core dumped, restarting

7. Removing the VF from the bridge stops this behaviour:
$ ovs-vsctl del-port br0 dpdk-p0

The same happens if I restart openvswitch between steps 4 and 5 and let it
initialize itself with the list of DPDK devices, instead of hotplugging
them at runtime, as described above.


On 11 January 2018 at 01:27, Riccardo Ravaioli <>

> Hi,
> I was going through the openvswitch+dpdk tutorial and wanted to add a
> virtual function (VF) to a bridge as a dpdk interface.
> I can bind the VF to the vfio-pci driver successfully with
>, but as soon as I add the interface to an ovs bridge (in
> netdev mode), openvswitch goes in segmentation fault and continuously tries
> to restart itself.
> I'm running openvswitch 2.8.1 and dpdk 17.11 on Debian jessie with Linux
> kernel 4.6.
> Is this a known problem? Is there a fix?
> I have the same issue with VFs bound to igb_uio, whereas with real
> physical interfaces it works just fine.
> Here are the relevant lines from ovs-vswitchd.log:
> 2018-01-10T15:53:26.949Z|00157|dpdk|INFO|PMD: igbvf_dev_configure(): VF
> can't disable HW CRC Strip
> 2018-01-10T15:53:26.949Z|00158|netdev_dpdk|ERR|Interface 0.extra2 MTU
> (1500) setup error: Operation not supported
> 2018-01-10T15:53:26.949Z|00159|netdev_dpdk|ERR|Interface 0.extra2(rxq:1
> txq:1) configure error: Operation not supported
> 2018-01-10T15:53:27.333Z|00066|daemon_unix(monitor)|ERR|fork child died
> before signaling startup (killed (Segmentation fault))
> 2018-01-10T15:53:27.333Z|00067|daemon_unix(monitor)|WARN|23 crashes: pid
> 21413 died, killed (Segmentation fault), core dumped, waiting until 10
> seconds since last restart
> 2018-01-10T15:53:33.333Z|00068|daemon_unix(monitor)|ERR|23 crashes: pid
> 21413 died, killed (Segmentation fault), core dumped, restarting
> Thanks!
> Riccardo
discuss mailing list

Reply via email to