From nobody Mon Sep 26 16:49:39 2022 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MbpdP08W6z4YG3v for ; Mon, 26 Sep 2022 16:49:45 +0000 (UTC) (envelope-from jrf@ursamaris.org) Received: from pb-smtp1.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MbpdM6dNkz3DBQ; Mon, 26 Sep 2022 16:49:43 +0000 (UTC) (envelope-from jrf@ursamaris.org) Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 1EFE11429BD; Mon, 26 Sep 2022 12:49:42 -0400 (EDT) (envelope-from jrf@ursamaris.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= content-type:content-transfer-encoding:from:mime-version:subject :date:message-id:references:cc:in-reply-to:to; s=sasl; bh=rew14O zdFw88Qf4qTE98/N/iLEtggiuhFyG7PB+m47M=; b=fcMfrwYLLnZ1numnyIl6gn X7lvDghoWQReK6F5/sjGxXSNK+YXYPn4GvNPjGsjjM4zjFKw82FSXSU2lpuHawNc fApzokRcJJ6QG1g5BPTpLD7PmGXdSZhnE6wULW3TJr/+mb9e9IBXYr7gpFiIujmQ wxJgVg0sSyosMbgXDvad8= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 0F8DB1429BB; Mon, 26 Sep 2022 12:49:42 -0400 (EDT) (envelope-from jrf@ursamaris.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=ursamaris.org; h=content-type:content-transfer-encoding:from:mime-version:subject:date:message-id:references:cc:in-reply-to:to; s=mesmtp; bh=rew14OzdFw88Qf4qTE98/N/iLEtggiuhFyG7PB+m47M=; b=E+tnnRK5Go0LJyRq5TB4cI5lAfWv2rbnXXU0I4dQaGxhZbt0x2w0t9VGWv11wNw27V5qoQxivhD7alhDTLp+7g1GtdtomcfCSlt31mEmChUyGUEpNoBuiH74LNvs6kcsAA2/W1V/P3sOfKjUHm/7QSyaYaawkGUoEY4W7JMRugI= Received: from smtpclient.apple (unknown [174.21.78.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 575591429BA; Mon, 26 Sep 2022 12:49:41 -0400 (EDT) (envelope-from jrf@ursamaris.org) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: John Fieber List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org Mime-Version: 1.0 (1.0) Subject: Re: igc problems with heavy traffic (update) Date: Mon, 26 Sep 2022 09:49:39 -0700 Message-Id: <244B1651-9A4D-4E38-A89B-B1610992A249@ursamaris.org> References: Cc: "Pieper, Jeffrey E" , Jim King , stable@freebsd.org, kbowling@freebsd.org In-Reply-To: To: mike tancsa X-Mailer: iPad Mail (19H12) X-Pobox-Relay-ID: 37446EBA-3DBB-11ED-A86F-2AEEC5D8090B-26150348!pb-smtp1.pobox.com X-Rspamd-Queue-Id: 4MbpdM6dNkz3DBQ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pobox.com header.s=sasl header.b=fcMfrwYL; dkim=pass header.d=ursamaris.org header.s=mesmtp header.b=E+tnnRK5; dmarc=pass (policy=reject) header.from=ursamaris.org; spf=pass (mx1.freebsd.org: domain of jrf@ursamaris.org designates 64.147.108.70 as permitted sender) smtp.mailfrom=jrf@ursamaris.org X-Spamd-Result: default: False [-3.60 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[ursamaris.org,reject]; R_SPF_ALLOW(-0.20)[+ip4:64.147.108.0/24]; R_DKIM_ALLOW(-0.20)[pobox.com:s=sasl,ursamaris.org:s=mesmtp]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.108.70:from]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:19151, ipnet:64.147.108.0/24, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[stable@freebsd.org]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[pobox.com:+,ursamaris.org:+]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[pobox.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On Sep 26, 2022, at 5:57 AM, mike tancsa wrote: >=20 > =EF=BB=BFOn 9/24/2022 8:30 PM, John Fieber wrote: >>>> On Sep 14, 2022, at 8:03 AM, mike tancsa wrote: >>>=20 >>> OK, an update hence the top post. I got a new pair of boxes which use a d= ifferent Jasper Lake chipset and have i226-V vs the i225 of the previous box= . >>>=20 >>> dev.igc.0.%parent: pci2 >>> dev.igc.0.%pnpinfo: vendor=3D0x8086 device=3D0x125c subvendor=3D0x8086 s= ubdevice=3D0x0000 class=3D0x020000 >>> dev.igc.0.%location: slot=3D0 function=3D0 dbsf=3Dpci0:2:0:0 handle=3D\_= SB_.PC00.RP05.PXSX >>> dev.igc.0.%driver: igc >>> dev.igc.0.%desc: Intel(R) Ethernet Controller I226-V >>> dev.igc.%parent: >>>=20 >>> WIth a default RELENG_13, out of the box with no tweaks, I am NOT able t= o cause the transmitting nic to bounce with heave traffic. I used the same t= est script (a constant stream of iperf3 alternating in direction) maxing out= the NIC's bandwidth and all seems fine running the test for some 18hrs. Ma= ybe something different about the i225 version of this NIC that needs some d= ifferent driver defaults ? >>>=20 >>> ---Mike >>>=20 >> I also see this behavior with 13.1-RELEASE-p2 on: >>=20 >> These, however, offer unflappable performance: >>=20 >> - FreeBSD-14.0-CURRENT-amd64-20220923 >> - vyos-1.4 (for reference, what I mostly use on this hardware, via bhyve)= >>=20 > Interesting, so just to confirm, the same hardware i225, the igc under 14.= x does not see link drops under heavy load ? I wonder what the difference i= s, since the driver does not seem to be different ? Correct. NIC chips are SLNMH, B3 stepping. All the other OS versions starte= d dropping within a minute. 14-CURRENT ran for an hour at about 2.3 gigabit w= ithout a single hiccup. All the tests were done with a fresh OS install in b= hyve (with pci passthrough for the nics) followed by =E2=80=9Cpkg install ip= erf3=E2=80=9D and no other tweaks. The switch port was configured with flow c= ontrol and EEE off in all cases. I ran the tests with the test OS as the iperf client, with -R and -P4 argume= nts. -R was always the quickest failure path. The hour long run on 14-CURREN= T was with --bidi, after -R alone failed to fail after five minutes. The hardware in question is my spare one of three identical 4x2.5g ali-expre= ss celeron J4125 boxes, and as such open for more and/or longer experiments.= (My spare time to fiddle is a bigger constraint.) -john