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.
