Hi Ian, Thanks for looking into the issue. Anything new?
Thanks a lot! Riccardo On 11 January 2018 at 23:50, Stokes, Ian <[email protected]> wrote: > Hi Ricardo, > > > > That’s for reporting the issue and providing the steps to reproduce. > > > > I was able to reproduce this with an i40e VF using igb_uio. > > > > In short it seems there is no support currently for ixgbe and i40e VF > devices in OVS with DPDK. > > > > There are 2 issues at play here. First is the configuration error when > creating and starting the VF in DPDK, the second issue is the Segfault in > OVS. > > > > The configuration of the VF fails (For the i40e device at least) because > of the expectation in DPDK that the HW_CRC stripping flag is enabled in the > device configuration for VFs. In your logs you will see an error reporting > this. By default this seems to be disabled for VFs in OVS. > > > > Looking in the DPDK code this is confirmed by the following in > i40evf_dev_configure() which code execution hits > > > > │1568 /* For non-DPDK PF drivers, VF has no ability to > disable HW > > > > │1569 * CRC strip, and is implicitly enabled by the > PF. > > > > │1570 */ > > > > > │1571 if (!conf->rxmode.hw_strip_crc) > { > > > > │1572 vf = I40EVF_DEV_PRIVATE_TO_VF(dev-> > data->dev_private); > > > > │1573 if ((vf->version_major == > VIRTCHNL_VERSION_MAJOR) && > > > > │1574 (vf->version_minor <= > VIRTCHNL_VERSION_MINOR)) { > > > > │1575 /* Peer is running non-DPDK PF > driver. */ > > > > │1576 PMD_INIT_LOG(ERR, "VF can't disable > HW CRC Strip"); > > > > │1577 return -EINVAL; > > > > > │1578 } > > > > Out of interest I enabled HW_CRC in the configuration for the device > manually in the ovs code for testing purposes. Although this allows the > queue configuration to succeed the VF will later fail to start due to an > issue with VSI queue mapping when DPDK attempts to start the device. I’ll > have to take another look to see what exactly is going wrong here, I > suspect there is more configuration needed for VFs than PFs. > > > > The segmentation fault happens due to the error occurring during the > dpdk_eth_dev_queue_setup() function, this is a separate issue and unrelated > to VFs. I have seen failures in this area cause segmentation faults before > in OVS so it’s an area that needs to be looked at again to handle DPDK > errors properly IMO. > > > > I hope this answers your question and I’ll follow up once I have a little > more info on how to enable the VF functionality. > > > > Thanks > > Ian > > > > > > > > *From:* [email protected] [mailto:ovs-discuss-bounces@ > openvswitch.org] *On Behalf Of *Riccardo Ravaioli > *Sent:* Thursday, January 11, 2018 10:27 AM > *To:* [email protected] > *Subject:* Re: [ovs-discuss] segmentation fault when adding a VF in DPDK > to a switch > > > > 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 dpdk-devbind.py: > $ dpdk-devbind.py --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: > $ dpdk-devbind.py --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 > options:dpdk-devargs=0000:05:10.3 > > 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 > net_e1000_igb_vf > 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. > > Riccardo > > > > > > On 11 January 2018 at 01:27, Riccardo Ravaioli <[email protected]> > wrote: > > 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 > dpdk-devbind.py, 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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
