From nobody Wed Jul 26 13:43:07 2023 X-Original-To: freebsd-net@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 4R9w8S70ZQz4pGmt for ; Wed, 26 Jul 2023 13:43:20 +0000 (UTC) (envelope-from ccfreebsd@gmail.com) Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R9w8S5PKBz4JY6 for ; Wed, 26 Jul 2023 13:43:20 +0000 (UTC) (envelope-from ccfreebsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ot1-f50.google.com with SMTP id 46e09a7af769-6bb14015560so4319286a34.2 for ; Wed, 26 Jul 2023 06:43:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690378999; x=1690983799; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UmYEZ3bDlBI36fbXpTt4LutSa+52lNnlLsxEScNlseM=; b=HX56GlbNG1hALidrGUER3UxblXhfQkaB+oqHUfSP/T1uvcgymVhCBE+8McWJnIPWTy /fgU/4JLyf3+6nKgf5ANglmLenF/uhuPEIgKjfnBLSRP16yzxX2TojXs1MQHWvlbtHg9 vfhQBpiP4Tu/uqoaaj7CwoCYw+t7O6HICnzzFVDyaTkpvPXyrZeHt2GrbqbpGGJNljYD UgVAbeqLyyh826z2g5LUZGJp6VbDkxQ56O5X3XsexMakNsJDMOJU7Y/uBX/skXFuNaEo rJNAFeSUkXOVQzh/ydOywMrAU9kvrYKSaUT8xq4NKSRTpr9XBdTI4IDd9HXFieoxvRsk re0w== X-Gm-Message-State: ABy/qLYng9jF/qjvoqZWGQL9qLipc2ziu2qGC2ts6bhzKNHblBumJ94V +1ocI72dn+3XkncXqMAHNoE+3rRaEUc= X-Google-Smtp-Source: APBJJlGV9auaZxUgqCbgOexbNISHPYyOuJr/IFShhGJXa4ykZ6TbJhF+vaj4S7v6ZaadkeIjfiWTGw== X-Received: by 2002:a05:6870:d10a:b0:1b7:16f3:d37f with SMTP id e10-20020a056870d10a00b001b716f3d37fmr2906901oac.17.1690378998799; Wed, 26 Jul 2023 06:43:18 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com. [209.85.210.42]) by smtp.gmail.com with ESMTPSA id v26-20020a9d4e9a000000b006b9d8c31e94sm5844782otk.39.2023.07.26.06.43.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jul 2023 06:43:18 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id 46e09a7af769-6b9c90527a0so5601522a34.1 for ; Wed, 26 Jul 2023 06:43:18 -0700 (PDT) X-Received: by 2002:a05:6870:548c:b0:1bb:8a0e:be4 with SMTP id f12-20020a056870548c00b001bb8a0e0be4mr2435843oan.14.1690378998349; Wed, 26 Jul 2023 06:43:18 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Cheng Cui Date: Wed, 26 Jul 2023 09:43:07 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: CFT: lem(4), em(4) e1000 Ethernet TSO testing To: Kevin Bowling Cc: FreeBSD Net Content-Type: multipart/alternative; boundary="000000000000bb8621060164075d" X-Rspamd-Queue-Id: 4R9w8S5PKBz4JY6 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated --000000000000bb8621060164075d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I didn't see your post covering 82541 or 82546 chips. Does this new em(4) change support TSO on these chips? If yes, I would be happy to test it on them. root@s1:~ # dmesg | grep 8254 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 em0: port 0xdcc0-0xdcff mem 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6 em1: port 0xccc0-0xccff mem 0xdf8e0000-0xdf8fffff irq 65 at device 8.0 on pci7 em2: port 0xbcc0-0xbcff mem 0xdf5e0000-0xdf5fffff irq 106 at device 4.0 on pci9 em3: port 0xbc80-0xbcbf mem 0xdf5c0000-0xdf5dffff irq 107 at device 4.1 on pci9 em4: port 0xacc0-0xacff mem 0xdf3e0000-0xdf3fffff irq 101 at device 3.0 on pci10 em5: port 0xac80-0xacbf mem 0xdf3c0000-0xdf3dffff irq 102 at device 3.1 on pci10 Best Regards, Cheng Cui On Tue, Jul 25, 2023 at 10:38=E2=80=AFPM Kevin Bowling wrote: > Hi, > > I have been working through various bugs and have come to a point > where TSO is working on systems I have available for testing. > > This results in higher throughput on resource constrained systems, and > less CPU/power usage on unconstrained systems. > > As of this mail, you will need to manually apply > https://reviews.freebsd.org/D41170 on top of main to use TSO6 on > em(4). > > I plan to enable TSO by default for lem(4) and em(4) during the > FreeBSD 14 release cycle, so I would appreciate testing to address any > remaining issues. Below, a list of chipsets that will be exempt due > to known issues. > > lem(4) exclusions: > * <82544 (although it does seem ok to manually enable for emulations > in qemu, virtualbox, etc) > * 82547 > > em(4) exclusions.. These chips have a stability workaround for high > throughput with rapid link-flap applied that results in the TSO engine > not being able to run at line speed. Thus, TSO would not be enabled > by default here: > * Intel(R) I219-LM and I219-V > * Intel(R) I219-LM and I219-V (2) > * Intel(R) I219-LM and I219-V (3) > * Intel(R) I219-LM and I219-V (4) > * Intel(R) I219-LM and I219-V (5) > > Regards, > Kevin Bowling > > --000000000000bb8621060164075d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I didn't see your post covering 82541 or 82546 ch= ips. Does this new em(4) change support TSO on these chips? If yes, I would= be happy to test it on them.

root@s1:~ # dmes= g | grep 8254
Timecounter "i8254" frequency 1193182 Hz quality= 0
Event timer "i8254" frequency 1193182 Hz quality 100
em0= : <Intel(R) Legacy PRO/1000 MT 82541GI> port 0xdcc0-0xdcff mem= 0xdfae0000-0xdfafffff irq 64 at device 7.0 on pci6
em1: <Intel(R) Le= gacy PRO/1000 MT 82541GI> port 0xccc0-0xccff mem 0xdf8e0000-0xdf8fffff i= rq 65 at device 8.0 on pci7
em2: <Intel(R) Legacy PRO/1000 MT 8254= 6EB (Copper)> port 0xbcc0-0xbcff mem 0xdf5e0000-0xdf5fffff irq 106 a= t device 4.0 on pci9
em3: <Intel(R) Legacy PRO/1000 MT 82546EB (Coppe= r)> port 0xbc80-0xbcbf mem 0xdf5c0000-0xdf5dffff irq 107 at device 4.1 o= n pci9
em4: <Intel(R) Legacy PRO/1000 MT 82546EB (Copper)> port 0x= acc0-0xacff mem 0xdf3e0000-0xdf3fffff irq 101 at device 3.0 on pci10
em5= : <Intel(R) Legacy PRO/1000 MT 82546EB (Copper)> port 0xac80-0xacbf m= em 0xdf3c0000-0xdf3dffff irq 102 at device 3.1 on pci10
<= div>
Best Regards,
Cheng Cui

=
On Tue= , Jul 25, 2023 at 10:38=E2=80=AFPM Kevin Bowling <kevin.bowling@kev009.com> wrote:
Hi,

I have been working through various bugs and have come to a point
where TSO is working on systems I have available for testing.

This results in higher throughput on resource constrained systems, and
less CPU/power usage on unconstrained systems.

As of this mail, you will need to manually apply
https://reviews.freebsd.org/D41170 on top of main to use TSO6 = on
em(4).

I plan to enable TSO by default for lem(4) and em(4) during the
FreeBSD 14 release cycle, so I would appreciate testing to address any
remaining issues.=C2=A0 Below, a list of chipsets that will be exempt due to known issues.

lem(4) exclusions:
* <82544 (although it does seem ok to manually enable for emulations
in qemu, virtualbox, etc)
* 82547

em(4) exclusions.. These chips have a stability workaround for high
throughput with rapid link-flap applied that results in the TSO engine
not being able to run at line speed.=C2=A0 Thus, TSO would not be enabled by default here:
* Intel(R) I219-LM and I219-V
* Intel(R) I219-LM and I219-V (2)
* Intel(R) I219-LM and I219-V (3)
* Intel(R) I219-LM and I219-V (4)
* Intel(R) I219-LM and I219-V (5)

Regards,
Kevin Bowling

--000000000000bb8621060164075d--