Date: Wed, 13 Feb 2019 00:54:35 +0100 From: Marius Strobl <marius@freebsd.org> To: rgrimes@FreeBSD.org Cc: John Baldwin <jhb@FreeBSD.org>, src-committers@FreeBSD.org, Patrick Kelsey <pkelsey@FreeBSD.org>, svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-stable-12@FreeBSD.org Subject: Re: svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net Message-ID: <20190212235435.GB92760@alchemy.franken.de> In-Reply-To: <201902120124.x1C1OI5b073609@pdx.rh.CN85.dnsmgr.net> References: <62d2dcc1-5bde-1eda-6d9f-82138932cb36@FreeBSD.org> <201902120124.x1C1OI5b073609@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 11, 2019 at 05:24:18PM -0800, Rodney W. Grimes wrote: > > On 2/11/19 4:26 PM, Rodney W. Grimes wrote: > > >> Author: pkelsey > > >> Date: Mon Feb 11 23:24:39 2019 > > >> New Revision: 344027 > > >> URL: https://svnweb.freebsd.org/changeset/base/344027 > > >> > > >> Log: > > >> MFC r343291: > > >> Convert vmx(4) to being an iflib driver. > > > > > > I strongly object to this MFC, given the current number > > > of 12.0 RELEASE related iflib problems we have it is > > > foolish of us to iflib any more drivers in 12.0 > > > > This isn't the release branch though and presumably we have some time before > > 12.1 ships. If there are reports of vmx(4) breakage on stable before 12.1 > > we could always revert this commit then? > > At this point the status if iflib in stable/12 is not certain, but > what is certain is this merge to 12 is probably going to break > someones system and at best is an unknown if working. > > People DO run stable/12, breaking it is a no no. > > Has the committer even booted this code in a stable/12 system > and run a serious amount of testing on it? > > > > > I've heard of some EN's for 12.0 for iflib fixes. Are those fixes in stable/12 > > yet or are we still waiting for them to land in HEAD and/or be merged? > > I sent a ping out earlier today trying to find that out. I belive that > some of them are merged to stable/12, some are waiting to be merged, I > do believe most if not all are commited to head. As for the iflib(4)-converted Intel Ethernet MAC drivers, it's hard to imagine how these drivers could have a chance of properly working on arm64 without r344060 and r344062 (which just hit head, with the latter breaking KBI) but also some previous iflib(4) fixes that were already MFCed to stable/12 (but aren't part of 12.0) in place. However, despite em(4) and ix(4) being in its GENERIC, I don't know what relevance these drivers actually have for arm64. So far, r343934 isn't in stable/12 either (I'll probably merge it tomorrow), fixing the problem with non-working 82583V a bunch of people ran into judging PRs. Last time I checked, there also were some other iflib(4)-related changes, e. g. to converted drivers, not done by me still missing in stable/12. As for the iflib(4) status in head, I'm aware of two remaining user-visible regressions I ran myself into when trying to use em(4) in production. 1) TX UDP performance is abysmal even when using multiple queues and, thus, MSI-X. In a quick test with netperf I see ~690 Mbits/s with 9216 bytes and 282 Mbits/s with 42080 bytes on a Xeon E3-1245V2 and 82574 with GigE connection (stable/11 e1000 drivers forward-ported to 12+ achieve 957 Mbit/s in both cases). 2) TX TCP performance is abysmal when using MSI or INTx (that's likely also PR 235031). I have an upcoming iflib(4) fix for 2) but don't have an idea what's causing 1) so far. I've identified two bugs in iflib(4) that likely have a minimal (probably more so with ixl(4), though) impact on UDP performance but don't explain the huge drop. Moreover, I have no idea so far how these relate to PR 234550. Regarding the latter, one obvious difference is that prior to the iflib(4)-conversions, the Intel Ethernet MAC drivers didn't engage software LRO when a VLAN ID is set. The actual reason why they didn't do that isn't obvious to me, though, and I found no other in-tree driver which behaves the same way, i. e. all employ software LRO now even when a VLAN ID is set. Personally, I don't see much point in issuing an iflib(4) EN for 12.0 before the above regressions have been fixed. Judging some PRs, people started using net/intel-em-kmod instead of the in-tree drivers, which IMO is the better option for now. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190212235435.GB92760>