Date: Wed, 13 Feb 2019 10:52:27 +0100 From: Michael Tuexen <Michael.Tuexen@macmic.franken.de> To: Marius Strobl <marius@freebsd.org> Cc: "rgrimes@freebsd.org" <rgrimes@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@FreeBSD.org>, Patrick Kelsey <pkelsey@FreeBSD.org>, "svn-src-stable@freebsd.org" <svn-src-stable@FreeBSD.org>, "svn-src-all@freebsd.org" <svn-src-all@FreeBSD.org>, "svn-src-stable-12@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: <19EE100C-4E78-40CB-BDAF-4833263A48D2@macmic.franken.de> In-Reply-To: <20190212235435.GB92760@alchemy.franken.de> References: <62d2dcc1-5bde-1eda-6d9f-82138932cb36@FreeBSD.org> <201902120124.x1C1OI5b073609@pdx.rh.CN85.dnsmgr.net> <20190212235435.GB92760@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 13. Feb 2019, at 00:54, Marius Strobl <marius@freebsd.org> 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: <PCI bus> on pcib0 pcib1: <PCI-PCI bridge> 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: <PCI bus> on pcib1 pcib0: pci_host_generic_core_alloc_resource FAIL: type=3D4, rid=3D28, = start=3D0000000000000000, end=3D0000000000000fff, = count=3D0000000000001000, flags=3D3000 ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver> 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: <Intel(R) PRO/10GbE PCI-Express Network Driver> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19EE100C-4E78-40CB-BDAF-4833263A48D2>