Re: [ovs-discuss] incoming packets truncated on I225 interface in OVS-DPDK
On Thu, 15 Apr 2021 at 15:31, Riccardo Ravaioli
wrote:
> I noticed something weird when using an I225 interface in OVS-DPDK:
> outgoing packets are processed normally, while incoming packets get
> truncated. In particular, starting from a certain IP packet length, the
> last 4 Bytes are always truncated.
> [...]
>
So we did a quick hack to force CRC stripping when the DPDK driver in use
is net_igc. It seems to work, but we're not too sure about possible side
effects.
Here is the patch:
diff -ru openvswitch-2.15.0.orig/lib/netdev-dpdk.c
openvswitch-2.15.0/lib/netdev-dpdk.c
--- openvswitch-2.15.0.orig/lib/netdev-dpdk.c2021-02-15
19:24:17.748074628 +0100
+++ openvswitch-2.15.0/lib/netdev-dpdk.c2021-04-21 15:21:20.575265997
+0200
@@ -1105,7 +1105,11 @@
if (strstr(info.driver_name, "vf") != NULL) {
VLOG_INFO("Virtual function detected, HW_CRC_STRIP will be
enabled");
dev->hw_ol_features |= NETDEV_RX_HW_CRC_STRIP;
+} else if (!strcmp(info.driver_name, "net_igc")) {
+VLOG_INFO("net_igc driver detected, HW_CRC_STRIP will be enabled");
+dev->hw_ol_features |= NETDEV_RX_HW_CRC_STRIP;
} else {
+VLOG_INFO("dpdk_eth_dev_init, HW_CRC_STRIP will be disabled");
dev->hw_ol_features &= ~NETDEV_RX_HW_CRC_STRIP;
}
What do you guys think?
Thanks!
Riccardo
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] incoming packets truncated on I225 interface in OVS-DPDK
hash_mac_addrs="0", max_mac_addrs="16", max_rx_pktlen="1618", max_rx_queues="4", max_tx_queues="4", max_vfs="0", max_vmdq_pools="0", min_rx_bufsize="256", numa_id="0", pci-device_id="0x15f3", pci-vendor_id="0x8086", port_no="0"} type: dpdk I'm running OVS 2.15.0 with DPDK 20.11.0 on linux kernel 5.4.89. It is important to point out that this does NOT happen when the same interface is bound to its kernel driver (igc), or is in PCI passthrough to the VM or, most importantly, when in use by another DPDK application (a router dataplane) compiled with the same DPDK version. Any ideas on the root cause of this and how to fix it? Thanks! Best, Riccardo Ravaioli ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] DPDK link state
On Thu, 21 Feb 2019 at 15:08, Flavio Leitner wrote: > On Thu, Feb 21, 2019 at 02:58:16PM +0100, Riccardo Ravaioli wrote: > I see that the command "ovs-ofctl show $bridge" reports this. I'm just not > > sure if the VM needs to be told explicitly (in which case, the command > > "ovs-ofctl mod-port $switch $port up/down" doesn't seem to work) or > instead > > it has all the necessary means to know this through the DPDK library. > > What exactly you're trying to do? The host networking could be seen as > the network infra outside of the host and in this case the VM link is > actually the vhost port which is up & running. > Right. I know this is quite unorthodox, but I'm trying to see if I can propagate the link state of a physical interface to a virtual machine. With a regular network interface and a virtio interface on the VM, I can listen on a netlink socket for RTM_NEWLINK messages (on the host) and then run "virsh domif-setlink $domain $interface up/down": inside the virtual machine, the link state will change accordingly. I was wondering if in the case of DPDK + vhostuser I can do something similar. Thanks! Riccardo ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] DPDK link state
Hi, Let's say I have a basic setup with a Linux virtual machine with one vhostuser interface, a physical interface in DPDK mode, and an OVS switch with those two interfaces on it. Can the VM know when the link on the physical interface is up or down? I see that the command "ovs-ofctl show $bridge" reports this. I'm just not sure if the VM needs to be told explicitly (in which case, the command "ovs-ofctl mod-port $switch $port up/down" doesn't seem to work) or instead it has all the necessary means to know this through the DPDK library. Thanks! Riccardo ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] password in plain text?!
Hi all, Why is the mailing list memberships reminder sending me my password in plain text? That's not too nice... :) Can that be fixed? Thanks! Riccardo ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] support for kernel 4.19?
Hi, I see that the latest release of openvswitch (2.10.1) supports up to kernel 4.15. Is there by any chance an unstable/experimental branch of openvswitch that already supports kernel 4.19, which is the most recent LTS version of the Linux kernel? Otherwise, are there plans to support kernel 4.19 in the near future? Thanks! Regards, Riccardo Ravaioli ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] "could not add network device ethX to ofproto (File exists)"
On 25 April 2018 at 22:00, Ben Pfaff wrote: > On Fri, Apr 20, 2018 at 04:35:27PM +0200, Riccardo Ravaioli wrote: > > [...] > > ovs-vsctl: Error detected while setting up 'eth9': could not add network > > device eth9 to ofproto (File exists). See ovs-vswitchd log for details. > > [...] > > The interface is up and bound to the correct driver: > > # ip a show dev eth9 > > 206: eth9: mtu 1500 qdisc mq master > > ovs-system state UP group default qlen 1000 > > link/ether 00:90:0b:54:88:58 brd ff:ff:ff:ff:ff:ff > > "master ovs-system" means that the interface is already part of a Open > vSwitch bridge. Probably you added it to an Open vSwitch bridge some > funny way? What does "ovs-dpctl show" print? How about "brctl show"? > Yes, I was testing configurations with the same interface bound to DPDK, then in PCI-pt to a VM, and then added normally to a switch (as above). I'm not sure which exact sequence of configuration changes caused this, though. I'll try to repeat some tests and run the commands you suggested. Thanks! Riccardo ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] "could not add network device ethX to ofproto (File exists)"
Hi all,
I bumped into a configuration error while trying to add a physical network
interface to a switch:
$ ovs-vsctl add-br myswitch
$ ovs-vsctl add-port myswitch eth9
ovs-vsctl: Error detected while setting up 'eth9': could not add network
device eth9 to ofproto (File exists). See ovs-vswitchd log for details.
ovs-vsctl: The default log directory is "/opt/oa/var/log/openvswitch".
Then I go to the specified log file and I don't see much more:
2018-04-20T14:26:05.226Z|00174|dpif|WARN|system@ovs-system: failed to add
eth9 as port: File exists
2018-04-20T14:26:05.226Z|00175|bridge|WARN|could not add network device
eth9 to ofproto (File exists)
The interface is up and bound to the correct driver:
# ip a show dev eth9
206: eth9: mtu 1500 qdisc mq master
ovs-system state UP group default qlen 1000
link/ether 00:90:0b:54:88:58 brd ff:ff:ff:ff:ff:ff
# ls -l /sys/class/net/eth9/device/driver
lrwxrwxrwx 1 root root 0 Apr 20 14:21 /sys/class/net/eth9/device/driver ->
../../../../bus/pci/drivers/igb
Deleting the port or the switch and re-doing the steps above won't help.
What am I missing here?
Here are more details from ovsdb:
# ovs-vsctl list bridge myswitch
_uuid : 585d63aa-bcb4-467a-a206-fa71ce239fe6
auto_attach : []
controller : []
datapath_id : "aa635d587a46"
datapath_type : ""
datapath_version: ""
external_ids: {}
fail_mode : []
flood_vlans : []
flow_tables : {}
ipfix : []
mcast_snooping_enable: false
mirrors : []
name: myswitch
netflow : []
other_config: {}
ports : [51c23178-5e3b-456d-bd91-f02358a06d16,
f0764ed6-197a-4d5f-962a-e9d9e3ede485]
protocols : []
rstp_enable : false
rstp_status : {}
sflow : []
status : {}
stp_enable : false
# ovs-vsctl list port eth9
_uuid : f0764ed6-197a-4d5f-962a-e9d9e3ede485
bond_active_slave : []
bond_downdelay : 0
bond_fake_iface : false
bond_mode : []
bond_updelay: 0
cvlans : []
external_ids: {}
fake_bridge : false
interfaces : [823e7827-4a34-4aa6-98aa-dc5964d456c6]
lacp: []
mac : []
name: "eth9"
other_config: {}
protected : false
qos : []
rstp_statistics : {}
rstp_status : {}
statistics : {}
status : {}
tag : []
trunks : []
vlan_mode : []
# ovs-vsctl list interface eth9
_uuid : 823e7827-4a34-4aa6-98aa-dc5964d456c6
admin_state : []
bfd : {}
bfd_status : {}
cfm_fault : []
cfm_fault_status: []
cfm_flap_count : []
cfm_health : []
cfm_mpid: []
cfm_remote_mpids: []
cfm_remote_opstate : []
duplex : []
error : "could not add network device eth9 to ofproto (File
exists)"
external_ids: {}
ifindex : []
ingress_policing_burst: 0
ingress_policing_rate: 0
lacp_current: []
link_resets : []
link_speed : []
link_state : []
lldp: {}
mac : []
mac_in_use : []
mtu : []
mtu_request : []
name: "eth9"
ofport : -1
ofport_request : []
options : {}
other_config: {}
statistics : {}
status : {}
type: ""
Thanks!
Riccardo
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] segmentation fault when adding a VF in DPDK to a switch
Hi Ian, Thanks a lot for your patch. I applied your modifications and ran again the setup described in the original post. While the CRC-related error message has disappeared, openvswitch still crashes (with no gdb running!): # tail ovs-vswitchd.log 2018-03-07T14:58:53.311Z|00215|dpdk|INFO|EAL: PCI device :05:10.1 on NUMA socket 0 2018-03-07T14:58:53.311Z|00216|dpdk|INFO|EAL: probe driver: 8086:1520 net_e1000_igb_vf 2018-03-07T14:58:53.518Z|00217|dpdk|INFO|PMD: eth_igbvf_dev_init(): VF MAC address not assigned by Host PF 2018-03-07T14:58:53.518Z|00218|dpdk|INFO|PMD: eth_igbvf_dev_init(): Assign randomly generated MAC address fe:00:a5:78:49:2a 2018-03-07T14:58:53.518Z|00219|netdev_dpdk|INFO|Device ':05:10.1' attached to DPDK 2018-03-07T14:58:53.518Z|00220|netdev_dpdk|ERR|Interface 2.switch1 MTU (1500) setup error: Operation not supported 2018-03-07T14:58:53.518Z|00221|netdev_dpdk|ERR|Interface 2.switch1(rxq:1 txq:1) configure error: Operation not supported 2018-03-07T14:58:53.884Z|2|daemon_unix(monitor)|ERR|1 crashes: pid 4171 died, killed (Segmentation fault), core dumped, restarting # lspci -s :05:10.1 -v 05:10.1 Ethernet controller: Intel Corporation I350 Ethernet Controller Virtual Function (rev 01) Flags: bus master, fast devsel, latency 0 [virtual] Memory at fbea (64-bit, prefetchable) [size=16K] [virtual] Memory at fbe8 (64-bit, prefetchable) [size=16K] Capabilities: [70] MSI-X: Enable- Count=3 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [150] Alternative Routing-ID Interpretation (ARI) Capabilities: [1a0] Transaction Processing Hints Capabilities: [1d0] Access Control Services Kernel driver in use: vfio-pci This is indeed the second issue you mentioned in a previous post. Can we get past this with a workaround? Thanks again! Riccardo On 7 March 2018 at 14:41, Stokes, Ian wrote: > Hi Ricardo, > > > > After some more time to look at the issue you could do something like > below to enable crc for the interface (Note I haven’t fully validated this). > > > > diff --git a/lib/netdev-dpdk.c b/lib/netdev-dpdk.c > > index af9843a..28d7d1e 100644 > > --- a/lib/netdev-dpdk.c > > +++ b/lib/netdev-dpdk.c > > @@ -700,6 +700,12 @@ dpdk_eth_dev_queue_setup(struct netdev_dpdk *dev, > int n_rxq, int n_txq) > > > > conf.rxmode.hw_ip_checksum = (dev->hw_ol_features & > >NETDEV_RX_CHECKSUM_OFFLOAD) != 0; > > + > > +/* > > + * Need to enable hw_strip_crc specifically for SRIOV devices. > > + */ > > +conf.rxmode.hw_strip_crc = 1; > > + > > > > On my system this at least got past the configuration error when adding > the SRIOV VF port and I was able to pass traffic through the port in a > simple VF to phy port setup . As I’ve only completed minor validation on > this maybe you could give it a shot and see if it works on your setup. > > > > With regards to the VSI queue error I mentioned in previous posts, with > some more investigation I found this only occurred when running the setup > of SRIOV VFs in DPDK with GDB, I was able to reproduce the same issue in > the DPDK l2fwd sample app so it is not specific to OVS. Once you are not > running OVS with GDB during the SRIOV setup it should be OK. I’ll need to > look at this in a little bit more detail when I have time but for the > moment it shouldn’t block you. > > > > Hope this helps, > > > > Regards > > Ian > > > > > > > > *From:* ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-bounces@ > openvswitch.org] *On Behalf Of *Stokes, Ian > *Sent:* Thursday, February 1, 2018 11:52 AM > *To:* riccardoravai...@gmail.com > > *Cc:* ovs-discuss@openvswitch.org > *Subject:* Re: [ovs-discuss] segmentation fault when adding a VF in DPDK > to a switch > > > > Hi Ricardo, > > > > Apologies for the delay. Unfortunately with the OVS 2.9 release I haven’t > had much time to look at this further. > > > > At the very least I think work needs to be done for dpdk.c and > netdev-dpdk.c to enable configuration of VFs specifically (to account for > the HW_CRC and VSI queue configurations). > > > > There would also be a task to ensure the work required for enabling a VF > on the i40e driver would also cover enabling a VF for the ixgbe driver. In > DPDK it’s been the case in the past that driver implementations for > different NIC devices can differ. > > > > This could be looked at in the OVS 2.10 development cycle at some point. I > can post an update here when there is progress. > > > > Thanks > > Ian > > > > *From:* sc
[ovs-discuss] cannot start a VM with vhostuser interfaces
Hi,
I'm having trouble starting a VM with vhostuser interfaces and I'm not sure
if it's due to my configuration of libvirt or of openvswitch.
I have a simple configuration where a VM running Debian has 1 vhostuser
interface plugged into an OVS switch where a DPDK interface is already
plugged in.
$ ovs-vsctl show:
Bridge "switch1"
Port "switch1"
Interface "switch1"
type: internal
Port "1.switch1"
Interface "1.switch1"
type: dpdk
options: {dpdk-devargs=":0b:00.0"}
Port "0.switch1"
Interface "0.vm"
type: dpdkvhostuserclient
options: {vhost-server-path="/opt/oa/vhost/0.vm.sock"}
The relevant excerpt from the XML of my VM is:
http://libvirt.org/schemas/domain/qemu/1.0";>
/opt/oa/bin/qemu-system-x86_64
Now, if I try to start my VM, I get the following error and the VM is not
started at all:
$ virsh create vm.xml
error: Failed to create domain from vm.xml
error: unsupported configuration: scripts are not supported on interfaces
of type vhostuser
The logs from libvirtd.log say:
2018-02-22 09:18:24.982+: 2033: warning :
qemuProcessStartWarnShmem:4539 : Detected vhost-user interface without any
shared memory, the interface might not be operational
2018-02-22 09:18:24.982+: 2033: error : qemuBuildHostNetStr:3894 :
unsupported configuration: scripts are not supported on interfaces of type
vhostuser
The logs from qemu simply say:
2018-02-22 09:26:15.857+: shutting down, reason=failed
And finally, ovs-vswitchd.log:
2018-02-22T09:18:24.715Z|00328|dpdk|INFO|VHOST_CONFIG: vhost-user client:
socket created, fd: 51
2018-02-22T09:18:24.716Z|00329|netdev_dpdk|INFO|vHost User device '0.vm'
created in 'client' mode, using client socket '/opt/oa/vhost/0.vm.sock'
2018-02-22T09:18:24.718Z|00330|dpdk|WARN|VHOST_CONFIG: failed to connect to
/opt/oa/vhost/0.vm.sock: No such file or directory
2018-02-22T09:18:24.718Z|00331|dpdk|INFO|VHOST_CONFIG:
/opt/oa/vhost/0.vm.sock: reconnecting...
2018-02-22T09:18:24.718Z|00332|bridge|INFO|bridge switch1: added interface
0.vm on port 5
Am I missing something on the openvswitch or on the libvirt side?
It looks like openvswitch can't find /opt/oa/vhost/0.vm.sock, but isn't
either openvswitch or libvirt in charge of creating it?
Then, I'm not too sure about the error messages in libvirtd.log...
My software versions are: libvirt 3.10.0, qemu 2.10.2, openvswitch 2.8.1
and DPDK 17.11.
Thanks a lot!
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] access ovsdb in Python
Hi, I need to query ovsdb to find out the current topology of bridges, switches and interfaces. So far I've been launching ovs-vsctl as an external process from my Python script and each such query takes between 10 and 15 milliseconds. The number of queries increases linearly with the number of bridges/ports/interfaces, so I'm looking for a faster way to access ovsdb from Python code. I see there's a subdirectory Python in the github repository of openvswitch, but it doesn't seem to be too documented. Is this what I'm looking for? If so, are there any examples on how to use it? https://github.com/openvswitch/ovs/tree/master/python/ Thanks! Riccardo ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] segmentation fault when adding a VF in DPDK to a switch
Hi Ian,
Thanks for looking into the issue. Anything new?
Thanks a lot!
Riccardo
On 11 January 2018 at 23:50, Stokes, Ian 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 */
>
>
>
>
>│1571if (!conf->rxmode.hw_strip_crc)
> {
>
>
>
>│1572vf = I40EVF_DEV_PRIVATE_TO_VF(dev->
> data->dev_private);
>
>
>
>│1573if ((vf->version_major ==
> VIRTCHNL_VERSION_MAJOR) &&
>
>
>
>│1574(vf->version_minor <=
> VIRTCHNL_VERSION_MINOR)) {
>
>
>
>│1575/* Peer is running non-DPDK PF
> driver. */
>
>
>
>│1576PMD_INIT_LOG(ERR, "VF can't disable
> HW CRC Strip");
>
>
>
>│1577return -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:* ovs-discuss-boun...@openvswitch.org [mailto:ovs-discuss-bounces@
> openvswitch.org] *On Behalf Of *Riccardo Ravaioli
> *Sent:* Thursday, January 11, 2018 10:27 AM
> *To:* ovs-discuss@openvswitch.org
> *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
> :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 :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=: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 :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 Hos
Re: [ovs-discuss] OVS port name differ from interface name
In the example above my bridge name is br and my ports are named 0.br, 1.br, etc. It's just an example. I could have chosen myport0, myport1, etc. On 18 January 2018 at 14:39, Shivaram Mysore wrote: > There is s typo in add-br command. Your bridge name is br instead of 0.br > > > > /Shivaram > ::Sent from my mobile device:: > > On Jan 18, 2018, at 5:17 AM, Riccardo Ravaioli > wrote: > > Hi Ben, > > I have a related question. I do the following in order to have a bridge br > with ports 0.br, 1.br... and later add existing interfaces to such ports: > > ovs-vsctl add-br br > ovs-vsctl add-port br 0.br > ovs-vsctl --id=@ifce create interface name=eth1 -- set port 0.br > interface=@ifce > > When I execute the "ovs-vsctl add-port' command above I get an error > saying that 0.br doesn't correspond to any interface: > *ovs-vsctl: Error detected while setting up '0.switch5': could not open > network device 0.switch5 (No such device).* > > Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is > just a switch port and not a real existing interface? > > > __ > > > On 15 January 2018 at 20:19, Ben Pfaff wrote: > >> On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote: >> >Is it possible to have an OVS port ‘name’ differ from the interface >> name? >> > >> > Bridge ovs-ha-sw >> > Port ovs-ha-sw >> > Interface ovs-ha-sw >> > type: internal >> > Port "bond1" >> > Interface "bond1" >> > >> > To have the effect of: >> > >> > Bridge ovs-ha-sw >> > Port ovs-ha-sw >> > Interface ovs-ha-sw >> > type: internal >> > Port “east-west" >> > Interface "bond1" >> >> You can do it, but since port names are immutable it has to happen at >> the time you add the port. For example: >> >> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0 >> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set >> port p0 name=asdf >> blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show >> 8b75cccb-f1eb-4e75-ac67-57ebac4e8432 >> Bridge "br0" >> Port "br0" >> Interface "br0" >> type: internal >> Port asdf >> Interface "p0" >> blp@sigabrt:~/nicira/ovs/tutorial(0)$ >> ___ >> discuss mailing list >> disc...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS port name differ from interface name
Hi Ben, I have a related question. I do the following in order to have a bridge br with ports 0.br, 1.br... and later add existing interfaces to such ports: ovs-vsctl add-br br ovs-vsctl add-port br 0.br ovs-vsctl --id=@ifce create interface name=eth1 -- set port 0.br interface=@ifce When I execute the "ovs-vsctl add-port' command above I get an error saying that 0.br doesn't correspond to any interface: *ovs-vsctl: Error detected while setting up '0.switch5': could not open network device 0.switch5 (No such device).* Can I pass an argument to "ovs-vsctl add-port" to tell OVS that 0.br is just a switch port and not a real existing interface? __ On 15 January 2018 at 20:19, Ben Pfaff wrote: > On Mon, Jan 15, 2018 at 09:50:52AM -0800, Fred Licht wrote: > >Is it possible to have an OVS port ‘name’ differ from the interface > name? > > > > Bridge ovs-ha-sw > > Port ovs-ha-sw > > Interface ovs-ha-sw > > type: internal > > Port "bond1" > > Interface "bond1" > > > > To have the effect of: > > > > Bridge ovs-ha-sw > > Port ovs-ha-sw > > Interface ovs-ha-sw > > type: internal > > Port “east-west" > > Interface "bond1" > > You can do it, but since port names are immutable it has to happen at > the time you add the port. For example: > > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-br br0 > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl add-port br0 p0 -- set > port p0 name=asdf > blp@sigabrt:~/nicira/ovs/tutorial(0)$ ovs-vsctl show > 8b75cccb-f1eb-4e75-ac67-57ebac4e8432 > Bridge "br0" > Port "br0" > Interface "br0" > type: internal > Port asdf > Interface "p0" > blp@sigabrt:~/nicira/ovs/tutorial(0)$ > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
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 :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 :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=: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 :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 ':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|2|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 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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] segmentation fault when adding a VF in DPDK to a switch
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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
