https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252015
Josef 'Jeff' Sipek <jef...@josefsipek.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jef...@josefsipek.net
--- Comment #4 from Josef 'Jeff' Sipek <jef...@josefsipek.net> ---
I've also had LRO issues recently and it sounds like it's the same problem as
what this ticket describes. Disabling LRO seems to fix the performance
problem.
Sometimes jails on my server get really poor TCP performance - on the order of
10kB/s. Looking at tcpdump output, it looks like occasionally the jail
receives a packet that's bigger than the MTU (e.g., 2896 which is > 1500) which
causes the jail to ignore the packet. Then the first ~MTU-worth of data gets
retransmitted, the jail ACKs it, and things are ok for a little while before
the next >MTU packet arrives.
This is what it *looks like* in tcpdump output. I don't know what's actually on
the wire, but I suspect that the physical packets are correctly sized because
when I disable LRO (which was on by default), the packets never seem to exceed
the MTU and I get near line-speed TCP performance.
I have seen this on a server with a number of vnet jails. Each jail has a
epair that's a member of bridge that's on a vlan on a lagg. More graphically:
em[02] -> lagg0 -> lagg0.31 -> bridge31 <- epairNa
That is, 2 e1000e cards are combined into lagg0. VLAN 31 on the lagg is a
member of the bridge31 bridge. Each jail gets an epair, and the host-side of
the epair is also a member of bridge31.
# uname -a
FreeBSD osiris 14.1-RELEASE-p3 FreeBSD 14.1-RELEASE-p3 GENERIC amd64
# freebsd-version -kru
14.1-RELEASE-p3
14.1-RELEASE-p3
14.1-RELEASE-p3
(I've also seen it on 14.0.)
host# ifconfig > /tmp/pre
host# ifconfig lagg0 -lro
host# ifconfig > /tmp/post
host# diff -u /tmp/pre /tmp/post
--- /tmp/pre 2024-08-10 14:12:11.812066000 +0000
+++ /tmp/post 2024-08-10 14:13:19.578057000 +0000
@@ -1,11 +1,11 @@
em0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
-
options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
+
options=4e520bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 00:25:90:50:81:ed
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
em2: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
-
options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
+
options=4e520bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 00:25:90:50:81:ed
hwaddr 00:25:90:50:81:ec
media: Ethernet autoselect
@@ -19,7 +19,7 @@
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
lagg0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
-
options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
+
options=4e520bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
ether 00:25:90:50:81:ed
hwaddr 00:00:00:00:00:00
laggproto lacp lagghash l2,l3
--
You are receiving this mail because:
You are the assignee for the bug.
