Date: Wed, 16 Aug 2023 21:14:42 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 272944] Vnet performance issues Message-ID: <bug-272944-227-0jN6ePMNrj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-272944-227@https.bugs.freebsd.org/bugzilla/> References: <bug-272944-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272944 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org Status|New |Open --- Comment #1 from Mark Johnston <markj@FreeBSD.org> --- I don't have a solution to propose, but at some level this is expected: pac= kets that get shuttled between two ends of an epair have to go through a single, global taskqueue thread. This means that there is no parallelization even = with multiple flows, and the handoff to the taskqueue thread may introduce some penalty. This is not ideal, but it's how it works out of the box. You didn't show the results with a single stream. If the problem appears t= o be tied to the number of flows, one thing you could try is enabling "options R= SS" in the kernel configuration; this introduces an epair worker thread per-CPU= . I suspect this would narrow the difference in your specific test. --=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-272944-227-0jN6ePMNrj>