Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Aug 2023 14:57:38 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 273046] xn0: xen netfront does LRO even if packet forwarding is enabled
Message-ID:  <bug-273046-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D273046

            Bug ID: 273046
           Summary: xn0: xen netfront does LRO even if packet forwarding
                    is enabled
           Product: Base System
           Version: 13.2-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: dfr@rabson.org

On a test VM running on an XCP-NG host, I noticed that large-receive was
happening on the VM's interface for traffic that was intended to be routed =
to a
vnet-enabled jail. The resulting large coalesced packets were too large to =
be
routed to the jail, causing retransmits and very slow performance inside the
vnet jail.

In my setup which uses podman to manage setting up network bridging for the
vnet jail, net.inet.ip.forwarding is set quite late and after network
interfaces are configured so I tried adding net.inet.ip.forwarding=3D1 to
sysctl.conf to see if that fixed the problem but the netfront driver was st=
ill
coalescing segments on receive - this is clearly visible in packet captures=
 as
oversized packets.

My impression from reading iflib.c was that LRO should not happen if packet
forwarding is enabled but netfront is missing this logic.

Based on user reports, this problem may also be present in the virtio vtnet
driver - one user reported slow podman network performance for a VM running=
 on
a Proxmox host.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-273046-227>