Date: Thu, 16 Mar 2023 19:39:53 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 268490] [igb] [lagg] [vlan]: Intel i210 performance severely degraded Message-ID: <bug-268490-7501-vWivjlMbql@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-268490-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-268490-7501@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=3D268490 --- Comment #31 from Kevin Bowling <kbowling@freebsd.org> --- (In reply to Daniel Duerr from comment #30) The idea is to bisect in somewhat of a reverse fashion where you introduce = the one line change on during each bisection step: - em_if_set_promisc(ctx, if_getflags(ifp)); + em_if_set_promisc(ctx, IFF_PROMISC); and see if that triggers a different resultant commit hash. Instead of wal= king backwards to see where things break, which you did, and which identified th= is line of code, we want to see when this line change results in bad performan= ce if it were applied earlier before, and during other code changes. If I understand correctly, applying this one line change to 12.2 did not result = in poor performance. If you have already done this and the performance is poo= r on 12.2 with the change there is no need to bisect further. The drivers are very similar between 12, 13, and 14 so if it is a driver regression it probably affects all of these. If it is some cross cut with = the network stack there could be something different but I am not aware of major differences in this area. --=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-268490-7501-vWivjlMbql>