The igb driver does not send any packets when requesting PKT_TX_VLAN_PKT. While the xmit-function returns success (number of tx pkts) no packets actually leave the NIC. Steps to reproduce: Get an Intel I350 and run the vhost-example application, like that ./vhost-switch -c 3 -n 1 -m 1400 -w 0000:04:00.0 -- -p 1 --socket-file /tmp/sock0 Attach a qemu and send a few pkts. Expected Result: tcpdump on a remote machine (direct cable connection) will see the pkts comming in. Actual Result: No Packets leaving the NIC. Additional Information: lspci of the NIC 04:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) Flags: fast devsel, IRQ 16 Memory at caa20000 (32-bit, non-prefetchable) [disabled] [size=128K] I/O ports at 3020 [disabled] [size=32] Memory at caa44000 (32-bit, non-prefetchable) [disabled] [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [70] MSI-X: Enable- Count=10 Masked- Capabilities: [a0] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-0a-cd-ff-ff-2d-ca-dc Capabilities: [150] Alternative Routing-ID Interpretation (ARI) Capabilities: [160] Single Root I/O Virtualization (SR-IOV) Capabilities: [1a0] Transaction Processing Hints Capabilities: [1c0] Latency Tolerance Reporting Capabilities: [1d0] Access Control Services Kernel driver in use: vfio-pci Kernel modules: igb Doing the VLAN-tagging in SW works as expected. Modified vhost to not set m->ol_flags |= PKT_TX_VLAN_PKT and instead called rte_vlan_insert(&m);
We found 17.05 and 18.02 to be affected by the problem, and probably every version inbetween. My personal guess would be a driver issue, ixgbe works as expected.
IGB driver should work well on PKT_TX_VLAN_PKT. Here's my test. HW: one IGB NIC with two ports connected each other. Port A is bound to igb_uio, the other port B keeps IGB kernel driver. 1. launch testpmd on port A ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i testpmd> set promisc all off testpmd> vlan set strip off 0 testpmd> vlan set filter off 0 testpmd> set mac fwd testpmd> port stop all testpmd> tx_vlan set 0 51 testpmd> port start all testpmd> start 2. port B send packet to port A >>> sendp(Ether(dst="A0:36:9F:03:98:E0")/IP(src="192.168.0.1", >>> dst="192.168.0.2")/UDP(sport=22, dport=23),iface="ens786f1") 3. check packet received on port B # tcpdump -i ens786f1 -Q in -nn -e 23:10:31.018730 a0:36:9f:03:98:e0 > 02:00:00:00:00:00, ethertype 802.1Q (0x8100), length 64: vlan 51, p 0, ethertype IPv4, 192.168.0.1.22 > 192.168.0.2.23: UDP, length 0 From the received packet, vlan ID is inserted successfully.
Thanks for looking into that. I can not reproduce it right now. Maybe my conclusion was wrong, but i did provide steps on how to reproduce the issue. Did you happen to try the steps i mentioned? Maybe the problem is not in the driver but in "vhost-switch".
Can you reply to Henning?
I used vhost-switch and followed the test steps you provided with dpdk-17.05 ,not found this issue , nic can receive packet and vlan ID is inserted successfully.
Seems like somehow our setups differ, and i am not sure whether there is an "official" reference setup described somewhere. I guess for me it would be time to reproduce the issue, and compare my system to what you did. Please tell me which Distro (kernel) you used, which dpdk config did you use, how did you configure hugepages ... and maybe other things that touch on dpdk. Not sure that could be the cause of the problem, but my configs differs from the defconfig: -CONFIG_RTE_IXGBE_INC_VECTOR=y +CONFIG_RTE_IXGBE_INC_VECTOR=n
HW: Get an Intel I350 NIC with two ports connected each other. Port A is bound to igb_uio, the other port B keeps IGB kernel driver. Steps to reproduce: 1. Port A is bound to igb_uio,then launch vhost-switch (tx_vector enabled by default) ./examples/vhost/build/vhost-switch -c 3 -n 4 --socket-mem 2048,2048 -- -p 0x1 --socket-file /tmp/sock0 2.Attach a qemu 3.Bind igb_uio driver and launch testpmd in VM,then send pkts ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i testpmd> set fwd mac testpmd> start tx_first 4. check packet received on port B # tcpdump -i enp177s0f1 -w /tmp/i350.pcap 5 Check received pkts with wireshark Test Result: Tcpdump can received packet from port B,and from the received packet, vlan ID is inserted successfully.
Can we close the defect if it is not reproducible anymore?
I can most likely reproduce it and will try to do so. If i can not i will close the issue myself.
Cant find a spare I350 anymore ... Closing.