From nobody Wed Dec 20 12:27:06 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 4SwCVp2cgkz54tkG for ; Wed, 20 Dec 2023 12:27:14 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SwCVp0JlFz4R18; Wed, 20 Dec 2023 12:27:14 +0000 (UTC) (envelope-from tuexen@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2003:a:e03:d412:1d58:5770:fa46:159c]) (Authenticated sender: micmac) by mail-n.franken.de (Postfix) with ESMTPSA id D873A721E2817; Wed, 20 Dec 2023 13:27:07 +0100 (CET) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Subject: Re: TSO + ECN From: tuexen@freebsd.org In-Reply-To: <1ad59f9a-1f8b-4e4b-8a78-5293d9e77776@freebsd.org> Date: Wed, 20 Dec 2023 13:27:06 +0100 Cc: FreeBSD Net Content-Transfer-Encoding: quoted-printable Message-Id: <9A07A31E-F5FF-4769-8A3A-3987F67AEBA5@freebsd.org> References: <1ad59f9a-1f8b-4e4b-8a78-5293d9e77776@freebsd.org> To: "Scheffenegger, Richard" X-Mailer: Apple Mail (2.3774.300.61.1.2) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_SCC_BODY_TEXT_LINE autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:193.174.0.0/15, country:DE] X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4SwCVp0JlFz4R18 > On Dec 20, 2023, at 12:15, Scheffenegger, Richard = wrote: >=20 > Hi, >=20 > I am curious if anyone here has expirience with the handling of ECN in = TSO-enabled drivers/hardware... Some data pointer if I read the specification correctly. Have a look at the specification of the 10GBit/sec card ix: https://cdrdv2-public.intel.com/331520/82599-datasheet-v3-4.pdf According to section 7.2.4 and 8.2.3.9.3 and 8.2.3.9.4 the * first segment gets all flags except PSH and FIN. * middle segments get all flags except PSH and FIN. * last segment gets all flags except the CWR. I think you should be able to change the masks. Best regards Michael >=20 > The other day I found that the virtio driver would bail out with = ENOTSUP when encountering the TCP CWR header bit on a TSO-enabled flow, = when the host does not also claim ECN-support for TSO. >=20 > But this made me wonder, how the expected behavior is. >=20 > Presumably, this means that the hardware (or driver) would clear the = CWR bit after the first packet is sent, correct? >=20 > However, in light of the upcoming AccECN signalling protocol, that is = not what TSO should be doing (with AccECN, all segments should retain = the exact same header flags, maybe expect PSH). >=20 > Probably "non-ECN" capable TSO offload would actually work better with = AccECN - and if the above behavior is what ECN-aware TSO is doing, = AccECN sessions would need to somehow work around that (e.g. = spoon-feeding any segment with CWR set individually - e.g. bypassing the = TSO capabilities in tcp_output)? >=20 >=20 > Would appreciate any feedback around this... >=20 > Best regards, > Richard >