From owner-svn-src-stable-12@freebsd.org Wed Feb 13 09:52:33 2019 Return-Path: Delivered-To: svn-src-stable-12@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4FB9014E9EF1; Wed, 13 Feb 2019 09:52:33 +0000 (UTC) (envelope-from Michael.Tuexen@macmic.franken.de) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91D648263A; Wed, 13 Feb 2019 09:52:32 +0000 (UTC) (envelope-from Michael.Tuexen@macmic.franken.de) Received: from [IPv6:2a02:c6a0:4015:12:454c:7dc4:bff5:6228] (unknown [IPv6:2a02:c6a0:4015:12:454c:7dc4:bff5:6228]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2B9827213B000; Wed, 13 Feb 2019 10:52:28 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: svn commit: r344027 - in stable/12/sys: dev/vmware/vmxnet3 modules/vmware/vmxnet3 net From: Michael Tuexen In-Reply-To: <20190212235435.GB92760@alchemy.franken.de> Date: Wed, 13 Feb 2019 10:52:27 +0100 Cc: "rgrimes@freebsd.org" , John Baldwin , "src-committers@freebsd.org" , Patrick Kelsey , "svn-src-stable@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-stable-12@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <19EE100C-4E78-40CB-BDAF-4833263A48D2@macmic.franken.de> References: <62d2dcc1-5bde-1eda-6d9f-82138932cb36@FreeBSD.org> <201902120124.x1C1OI5b073609@pdx.rh.CN85.dnsmgr.net> <20190212235435.GB92760@alchemy.franken.de> To: Marius Strobl X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: svn-src-stable-12@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for only the 12-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 09:52:33 -0000 > On 13. Feb 2019, at 00:54, Marius Strobl wrote: >=20 > 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 >>>>>=20 >>>>> Log: >>>>> MFC r343291: >>>>> Convert vmx(4) to being an iflib driver. >>>>=20 >>>> 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 >>>=20 >>> 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? >>=20 >> 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. >>=20 >> People DO run stable/12, breaking it is a no no. >>=20 >> Has the committer even booted this code in a stable/12 system >> and run a serious amount of testing on it? >>=20 >>>=20 >>> 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? >>=20 >> 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. >=20 > 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. Hi Marius, would love to use an ix(4) card on an Overdrive 3000 system. However, this doesn't really work, since there is a PCI related problem when booting. Sometimes the box works for a while, sometimes it doesn't come up: pci0: on pcib0 pcib1: at device 2.1 on pci0 pcib0: pci_host_generic_core_alloc_resource FAIL: type=3D4, rid=3D28, = start=3D0000000000000000, end=3D0000000000000fff, = count=3D0000000000001000, flags=3D0 pcib1: failed to allocate initial I/O port window: 0-0xfff pci1: on pcib1 pcib0: pci_host_generic_core_alloc_resource FAIL: type=3D4, rid=3D28, = start=3D0000000000000000, end=3D0000000000000fff, = count=3D0000000000001000, flags=3D3000 ix0: port 0x1000-0x101f = mem 0x7fffe80000-0x7fffefffff,0x7ffff04000-0x7ffff07fff at device 0.0 on = pci1 ix0: Using 2048 tx descriptors and 2048 rx descriptors ix0: Using 8 rx queues 8 tx queues ix0: Using MSI-X interrupts with 9 vectors ix0: allocated for 8 queues ix0: allocated for 8 rx queues ix0: Ethernet address: 90:e2:ba:f7:48:74 ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix1: mem = 0x7fffe00000-0x7fffe7ffff,0x7ffff00000-0x7ffff03fff at device 0.1 on = pci1 ix1: Using 2048 tx descriptors and 2048 rx descriptors ix1: Using 8 rx queues 8 tx queues ix1: Using MSI-X interrupts with 9 vectors ix1: allocated for 8 queues ix1: allocated for 8 rx queues ix1: Ethernet address: 90:e2:ba:f7:48:75 ix1: PCI Express Bus: Speed 5.0GT/s Width x8 jhb@ said that this is related to some PCI memory allocation limitation = on arm64, if I remember it correctly. I think that ref12-aarch64.freebsd.org uses an igb card. But I can't = login to verify... Best regards Michael > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Marius >=20 >=20