OK, I misunderstood Avinash's mail before, I thought I had to update the MTU on the physical device. I changed the MTU to 1500 in VPP now and I can resolve the address. So I guess that answers my own question too. :-)
/Tomas On 12 May 2017 at 17:34, Tomas Brännström <tomas.a.brannst...@tieto.com> wrote: > Hm, OK. > > I did a search for the HW CRC message earlier and it sounded like the > message was just for information and had no real functional impact, but > maybe it does.. (http://dpdk.org/dev/patchwork/patch/12080/) > > Would there be a workaround outside VPP for 2. somehow? > > /Tomas > > On 12 May 2017 at 16:30, Damjan Marion (damarion) <damar...@cisco.com> > wrote: > >> >> There are 2 problems: >> >> 1. HW CRC strip needs to be enabled for VFs, that’s why DPDK is failing >> to init device >> 2. VFs are dropping packets when .max_rx_pkt_len is set to 9216 >> >> Problem 1. is easy fixable by changing .hw_strip_crc to 1 in >> src/plugins/dpdk/device/init.c >> >> Problem 2. seems to be outside of VPP control, but it can be workarounded >> by setting .max_rx_pkt_len to 1518. consequence of doing this is that we >> will (likely) loose jumbo frame support on VFs. >> >> I’m going to submit patch which fixes both issues soon (actually >> workarounds 2. ), I need to play a bit more with 2. first... >> >> >> >> On 12 May 2017, at 12:08, Tomas Brännström <tomas.a.brannst...@tieto.com> >> wrote: >> >> Unfortunately my MTU seems to be at 1500 already. >> >> I did an upgrade to release 1704 and now none of the interfaces are >> discovered anymore. But it seems suspicious since there are basically no >> log printouts at startup either, below are 1701 vs 1704 for comparision. >> This isn't exclusive for this "SR-IOV" machine either I think, when running >> later VPP in for example virtual box I get the same problems, so I guess >> there's something additional that must be done that's maybe not documented >> on the wiki yet. >> >> 17.01: >> ------ >> vlib_plugin_early_init:213: plugin path /usr/lib/vpp_plugins >> vpp[5066]: vlib_pci_bind_to_uio: Skipping PCI device 0000:00:03.0 as host >> interface eth0 is up >> EAL: Detected 4 lcore(s) >> EAL: No free hugepages reported in hugepages-1048576kB >> EAL: Probing VFIO support... >> EAL: WARNING: cpu flags constant_tsc=yes nonstop_tsc=no -> using >> unreliable clock cycles ! >> EAL: PCI device 0000:00:03.0 on NUMA socket -1 >> EAL: Device is blacklisted, not initializing >> EAL: PCI device 0000:00:06.0 on NUMA socket -1 >> EAL: probe driver: 8086:10ed net_ixgbe_vf >> EAL: PCI device 0000:00:07.0 on NUMA socket -1 >> EAL: probe driver: 8086:10ed net_ixgbe_vf >> DPDK physical memory layout: >> Segment 0: phys:0x5cc00000, len:2097152, virt:0x7f7e0b800000, >> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 >> Segment 1: phys:0x5d000000, len:266338304, virt:0x7f7db1600000, >> socket_id:0, hugepage_sz:2097152, nchannel:0, nrank:0 >> PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip >> PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip >> >> 17.04: >> ------ >> vlib_plugin_early_init:360: plugin path /usr/lib/vpp_plugins >> >> /Tomas >> >> On 12 May 2017 at 11:49, Gonsalves, Avinash (Nokia - IN/Bangalore) < >> avinash.gonsal...@nokia.com> wrote: >> >>> I faced a similar issue with SR-IOV, and for some reason setting the MTU >>> size to 1500 on the interface helped with ARP resolution. >>> >>> >>> >>> Thanks, >>> Avinash >>> >>> >>> >>> ================================================================================ >>> >>> >>> >>> Thanks. I can try to use a later VPP version. A thing to note is that when >>> >>> we did try to use the master release before, VPP failed to discover >>> >>> interfaces, even when they were whitelisted. Not sure if something has >>> >>> changed in the way VPP discover interfaces in later versions. I will try >>> >>> with 1704 though. >>> >>> >>> >>> Ah OK sorry, should have realized what PF was in this context. Not sure of >>> >>> all the info that might be needed but here's what I could think of: >>> >>> >>> >>> root at node-4 <https://lists.fd.io/mailman/listinfo/vpp-dev>:~# lspci -t -v >>> >>> [...] >>> >>> +-03.0-[0b-0c]--+-00.0 Intel Corporation 82599ES 10-Gigabit >>> >>> SFI/SFP+ Network Connection >>> >>> | +-00.1 Intel Corporation 82599ES 10-Gigabit >>> >>> SFI/SFP+ Network Connection >>> >>> | +-10.0 Intel Corporation 82599 Ethernet >>> >>> Controller Virtual Function >>> >>> | +-10.1 Intel Corporation 82599 Ethernet >>> >>> Controller Virtual Function >>> >>> [...] >>> >>> >>> >>> root at node-4 <https://lists.fd.io/mailman/listinfo/vpp-dev>:~# lshw >>> -class network -businfo >>> >>> Bus info Device Class Description >>> >>> ============================================================ >>> >>> pci at 0000 <https://lists.fd.io/mailman/listinfo/vpp-dev>:0b:00.0 >>> enp11s0f0 network 82599ES 10-Gigabit >>> >>> SFI/SFP+ Network Connection >>> >>> pci at 0000 <https://lists.fd.io/mailman/listinfo/vpp-dev>:0b:00.1 >>> enp11s0f1 network 82599ES 10-Gigabit >>> >>> SFI/SFP+ Network Connection >>> >>> >>> >>> root at node-4 <https://lists.fd.io/mailman/listinfo/vpp-dev>:~# cat >>> /sys/class/net/enp11s0f0/device/sriov_totalvfs >>> >>> 63 >>> >>> >>> >>> root at node-4 <https://lists.fd.io/mailman/listinfo/vpp-dev>:~# cat >>> /sys/class/net/enp11s0f0/device/sriov_numvfs >>> >>> 16 >>> >>> >>> >>> root at node-4 <https://lists.fd.io/mailman/listinfo/vpp-dev>:~# ethtool -i >>> enp11s0f0 >>> >>> driver: ixgbe >>> >>> version: 3.15.1-k >>> >>> firmware-version: 0x61c10001 >>> >>> bus-info: 0000:0b:00.0 >>> >>> supports-statistics: yes >>> >>> supports-test: yes >>> >>> supports-eeprom-access: yes >>> >>> supports-register-dump: yes >>> >>> supports-priv-flags: no >>> >>> >>> >>> /Tomas >>> >>> >>> >>> On 12 May 2017 at 10:44, Damjan Marion (damarion) <damarion at cisco.com >>> <https://lists.fd.io/mailman/listinfo/vpp-dev>> >>> >>> wrote: >>> >>> >>> >>> > >>> >>> >* On 12 May 2017, at 08:01, Tomas Brännström <tomas.a.brannstrom at >>> >tieto.com <https://lists.fd.io/mailman/listinfo/vpp-dev>>* >>> >>> >* wrote:* >>> >>> > >>> >>> >* *(I forgot to mention before, this is running with VPP installed from* >>> >>> >* binaries with release .stable.1701)** >>> >>> > >>> >>> > >>> >>> >* I strongly suggest that you use 17.04 release at least.* >>> >>> > >>> >>> > >>> >>> >* With PF do you mean packet filter? I don't think we have any such* >>> >>> >* configuration. If there is anything else I should provide then please >>> >tell* >>> >>> >* :)* >>> >>> > >>> >>> > >>> >>> >* PF = SR-IOV Physical Function* >>> >>> > >>> >>> > >>> >>> >* I decided to try to attach to the VPP process with gdb and I actually >>> >get* >>> >>> >* a crash when trying to do "ip probe":* >>> >>> > >>> >>> >* vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0* >>> >>> >* exec error: Misc* >>> >>> > >>> >>> >* Program received signal SIGSEGV, Segmentation fault.* >>> >>> >* ip4_probe_neighbor (vm=vm at entry >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>=0x7f681533e720 >>> ><vlib_global_main>,* >>> >>> >* dst=dst at entry >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>=0x7f67d345cc50, >>> >sw_if_index=sw_if_index at entry >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>=1)* >>> >>> >* at /w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/* >>> >>> >* vnet/ip/ip4_forward.c:2223* >>> >>> >* 2223 >>> >/w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/vnet/ip/ip4_forward.c:* >>> >>> >* No such file or directory.* >>> >>> >* (gdb) bt* >>> >>> >* #0 ip4_probe_neighbor (vm=vm at entry >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>=0x7f681533e720 >>> ><vlib_global_main>,* >>> >>> >* dst=dst at entry >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>=0x7f67d345cc50, >>> >sw_if_index=sw_if_index at entry >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>=1)* >>> >>> >* at /w/workspace/vpp-merge-1701-ubuntu1404/build-data/../vnet/* >>> >>> >* vnet/ip/ip4_forward.c:2223* >>> >>> > >>> >>> >* Whether this is related or not I'm not sure because yesterday I could do* >>> >>> >* the probe but got "Resolution failed". I've attached the stack trace at >>> >any* >>> >>> >* rate.* >>> >>> > >>> >>> >* /Tomas* >>> >>> > >>> >>> >* On 11 May 2017 at 20:25, Damjan Marion (damarion) <damarion at cisco.com >>> ><https://lists.fd.io/mailman/listinfo/vpp-dev>>* >>> >>> >* wrote:* >>> >>> > >>> >>> >>* Dear Tomas,* >>> >>> >> >>> >>> >>* Can you please share your PF configuration so I can try to reproduce?* >>> >>> >> >>> >>> >>* Thanks,* >>> >>> >> >>> >>> >>* Damjan* >>> >>> >> >>> >>> >>* On 11 May 2017, at 17:07, Tomas Brännström <tomas.a.brannstrom at >>> >>tieto.com <https://lists.fd.io/mailman/listinfo/vpp-dev>>* >>> >>> >>* wrote:* >>> >>> >> >>> >>> >>* Hello* >>> >>> >>* Since the last mail I sent I've managed to get our test client working* >>> >>> >>* and VPP running in a KVM VM.* >>> >>> >> >>> >>> >>* We are still facing some problems though. We have a two servers, one* >>> >>> >>* where the virtual machines are running and one we use as the openstack* >>> >>> >>* controller. They are connected to each other with a 10G NIC. We have >>> >>SR-IOV* >>> >>> >>* configured for the 10G NIC.* >>> >>> >> >>> >>> >>* So VPP is installed in a VM, and all interfaces work OK, then can be* >>> >>> >>* reached from outside the VM etc. Following the basic examples on the >>> >>wiki,* >>> >>> >>* we configure VPP to take over the interfaces:* >>> >>> >> >>> >>> >>* vpp# set int ip address TenGigabitEthernet0/6/0 10.0.1.101/24 >>> >><http://10.0.1.101/24>* >>> >>> >>* vpp# set int ip address TenGigabitEthernet0/7/0 10.0.2.101/24 >>> >><http://10.0.2.101/24>* >>> >>> >>* vpp# set int state TenGigabitEthernet0/6/0 up* >>> >>> >>* vpp# set int state TenGigabitEthernet0/7/0 up* >>> >>> >> >>> >>> >>* But when trying to ping for example the physical NIC on the other >>> >>server,* >>> >>> >>* we get no reply:* >>> >>> >> >>> >>> >>* vpp# ip probe 10.0.1.1 TenGigabitEthernet0/6/0* >>> >>> >>* ip probe-neighbor: Resolution failed for 10.0.1.1* >>> >>> >> >>> >>> >>* If I do a tcpdump on the physical interface when trying to ping, I see* >>> >>> >>* ARP packets being sent so -something- is happening, but it seems that* >>> >>> >>* packets are not correctly arriving to VPP... I can't ping from the >>> >>physical* >>> >>> >>* host either, but the ARP cache is updated on the host when trying to >>> >>ping* >>> >>> >>* from VPP.* >>> >>> >> >>> >>> >>* I've tried dumping counters etc. but I can't really see anything. The* >>> >>> >>* trace does not show anything either. This is the output from "show* >>> >>> >>* hardware":* >>> >>> >> >>> >>> >>* vpp# show hardware* >>> >>> >>* Name Idx Link Hardware* >>> >>> >>* TenGigabitEthernet0/6/0 1 up TenGigabitEthernet0/6/0* >>> >>> >>* Ethernet address fa:16:3e:04:42:d1* >>> >>> >>* Intel 82599 VF* >>> >>> >>* carrier up full duplex speed 10000 mtu 9216* >>> >>> >>* rx queues 1, rx desc 1024, tx queues 1, tx desc 1024* >>> >>> >> >>> >>> >>* tx frames ok 3* >>> >>> >>* tx bytes ok 126* >>> >>> >>* extended stats:* >>> >>> >>* tx good packets 3* >>> >>> >>* tx good bytes 126* >>> >>> >>* TenGigabitEthernet0/7/0 2 up TenGigabitEthernet0/7/0* >>> >>> >>* Ethernet address fa:16:3e:f2:15:a5* >>> >>> >>* Intel 82599 VF* >>> >>> >>* carrier up full duplex speed 10000 mtu 9216* >>> >>> >>* rx queues 1, rx desc 1024, tx queues 1, tx desc 1024* >>> >>> >> >>> >>> >>* I've tried a similar setup between two virtual box VM's and that worked* >>> >>> >>* OK, so I'm thinking it might have something to do with SR-IOV for some* >>> >>> >>* reason. I'm having a hard time troubleshooting this since I'm not sure >>> >>how* >>> >>> >>* to check where the packets actually get lost...* >>> >>> >> >>> >>> >>* /Tomas* >>> >>> >> >>> >>> >>* _______________________________________________* >>> >>> >>* vpp-dev mailing list* >>> >>> >>* vpp-dev at lists.fd.io <https://lists.fd.io/mailman/listinfo/vpp-dev>* >>> >>> >>* https://lists.fd.io/mailman/listinfo/vpp-dev >>> >><https://lists.fd.io/mailman/listinfo/vpp-dev>* >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >* <vpp_stacktrace.txt>* >>> >>> > >>> >>> > >>> >>> > >>> >>> -------------- next part -------------- >>> >>> An HTML attachment was scrubbed... >>> >>> URL: >>> <http://lists.fd.io/pipermail/vpp-dev/attachments/20170512/5a0abc73/attachment.html> >>> >>> >>> >> >> _______________________________________________ >> vpp-dev mailing list >> vpp-dev@lists.fd.io >> https://lists.fd.io/mailman/listinfo/vpp-dev >> >> >> >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
