https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280386
fatal...@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fatal...@gmail.com --- Comment #5 from fatal...@gmail.com --- I just set up the same test the best I can (albeit a different IP address assigned to the bridge) and using an igb interface (Intel I350). I can not reproduce the problem on 14.0-RELEASE-p6. I can try again with 14.1 later this week but I can not bring this system I used for testing offline until then. After performing the same iperf3 test with the identical ifconfig parameters, connected to a bridge with the iperf client being the FreeBSD machine AND just for testing purposes the other way around: root@hv-kryptos:~ # sysctl dev.igb.0.iflib | grep r_drops dev.igb.0.iflib.txq7.r_drops: 0 dev.igb.0.iflib.txq6.r_drops: 0 dev.igb.0.iflib.txq5.r_drops: 0 dev.igb.0.iflib.txq4.r_drops: 0 dev.igb.0.iflib.txq3.r_drops: 0 dev.igb.0.iflib.txq2.r_drops: 0 dev.igb.0.iflib.txq1.r_drops: 0 dev.igb.0.iflib.txq0.r_drops: 0 I might need to push the system harder to get some error generation perhaps. What happens if you disable checksum offloading and / or segmentation offloading? Also, what sort of iperf stats are you getting? I am not quite reaching the full gigabit link rates on my interface, so I'd just like a reference in case this only happens when getting closer to the full link bandwidth. It also looks like our dmesg output differs a bit (particularly the option roms are different): igb0: <Intel(R) I350 (Copper)> port 0x6020-0x603f mem 0xc7a00000-0xc7afffff,0xc7c04000-0xc7c07fff irq 26 at device 0.0 numa-domain 0 on pci3 igb0: EEPROM V1.63-0 Option ROM V0-b385-p144 eTrack 0x80000e74 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: Using 8 RX queues 8 TX queues igb0: Using MSI-X interrupts with 9 vectors igb0: Ethernet address: 70:df:2f:ae:58:94 igb0: netmap queues/slots: TX 8/1024, RX 8/1024 -- You are receiving this mail because: You are the assignee for the bug.