From nobody Thu Aug 7 12:38:46 2025 X-Original-To: dev-commits-src-all@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 4byRYB3xpGz64DpB; Thu, 07 Aug 2025 12:38:54 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4byRY96pHzz3v3W; Thu, 07 Aug 2025 12:38:53 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1754570334; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GSLGE/afMcVsisblCE5cYrm3+AJgNq9oKFeMXK14oN8=; b=p7FSgM7rGR3eKjUdLVmjCpXo6DZXeBX3dEEIpgAR4FgFN9zs15HHd36ZQLpzTfGobIHq7/ ntlQGJ8AHGIE1uuTXriFuHrlNyBaKrYPeMd8r2WfxnTuW6p6OIlLQP2hFy8Ck3sluJAdGr ZOmupOwqEPRet/gQ8l0sGXA7h0FeNfJvA6CBljPN8Is+wh+e9AF2mTp0/qPqwVjJjftzFR q5dwKlgrtQttJLluNSryvatgm1+wNFOe1zECah1/dWfhFkcwMORfAS3AVc+VbHf7WuMa4V i21xF+qsfnEt1HTqZ5cxLwgJtL+t4SYtyYPDqTxZgJu4bLgo+cDHTGSahJtwmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1754570334; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GSLGE/afMcVsisblCE5cYrm3+AJgNq9oKFeMXK14oN8=; b=JyA0i7IVxx0r9uYy3nFop8gGyPx6oeXsMSgy7q24TLdM9m+SdO/dcQh+Zp1/7dVAFT0swP qFWulwfpd9C5rx5PDBqzJzrtzE6Pv/JEwhWzWOvqz8ckea2JI8dfGr7H8y6IWNGBUuyl6w QNYl/QzSpzU4mFD2gGiXpRMVlbMWj13URAVoEDDSsee8+Pk/5Z34a37JnDNysJWUY9TVTR a5/uVP4mC2M0eyDDZtJISX4KMqWe7/Q3RQkLuaNNbwe8FqUl1KQp2CTSDL8kmdbD99QSJO 8PmsIpoM1b8oiZz/M1Drp7wHRxO8ZFCCeWpB5Gt/QzUpdfRHvejjWghvzV7Wag== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1754570334; a=rsa-sha256; cv=none; b=G97F8bI8ylxRogrdqaXCMaNPeee5BsoOQZiunRmjtPeuwkbQczyBpb5weuyPu0odDmuW+W LaJN9tb4khMltCIyPijisLWJYbvKtknDoOM1qP1cbj/SVl+wtnDiJRXhIWCmZ2LkBVaGxo 4sHr6e89YezUNLM65GvXQXdVzO9t0MScKrWYW/Bi6jlo4vAqtWMrDlWFyN63ux7F7RAJWR P+aa+W4eo0j2Fc20cwuLGJPWOoaQ8s7a2sx2lP21MdCzn7Nu8YaYcF80cMCSKvhYzByzHX UOUhztH0AMiKXAwScERKrnIwAX0nu++xvuy4ARCXYiMu1mNjpRKPuOy1c9e1Mw== Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1101:be00:3835:31e9:a7ec:b401]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: tuexen) by smtp.freebsd.org (Postfix) with ESMTPSA id 4byRY92TkPz10RB; Thu, 07 Aug 2025 12:38:53 +0000 (UTC) (envelope-from tuexen@FreeBSD.org) Content-Type: text/plain; charset=us-ascii List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: git: bcb298fa9e23 - main - sctp, tcp, udp: improve deferred computation of checksums From: Michael Tuexen In-Reply-To: Date: Thu, 7 Aug 2025 14:38:46 +0200 Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <202508010817.5718HZM6067171@gitrepo.freebsd.org> To: Gleb Smirnoff X-Mailer: Apple Mail (2.3826.700.81) > On 7. Aug 2025, at 00:35, Gleb Smirnoff wrote: >=20 > Michael, >=20 > On Fri, Aug 01, 2025 at 08:17:35AM +0000, Michael Tuexen wrote: > M> When the SCTP, TCP, or UDP implementation send a packet, it = does not > M> compute the corresponding checksum but defers that. The network = layer > M> will determine whether the network interface selected for the = packet > M> has the requested capability and computes the checksum in = software, > M> if the selected network interface doesn't have the requested > M> capability. > M> Do this not only for packets being sent by the local SCTP, TCP, > M> and UDP stack, but also when forwarding packets. Furthermore, = when > M> such packets are delivered to a local SCTP, TCP, or UDP stack, = do not > M> compute or validate the checksum, since such packets never have = been on > M> the wire. > M> This allows to support checksum offloading also in the case of = local > M> virtual machines or jails. > M> Support for epair, vtnet, and tap interfaces will be added in > M> separate commits. >=20 > Not a request for any action, but a general comment on the topic. >=20 > Imagine we are developing an IP stack from scratch for modern = computers. Most > NICs do hardware checksumming, large fraction of installations run in A lot do checksum offloading for TCP/IPv[46] and UDP/IPv[46]. But only = some do it for SCTP/IPv[46]. Also support for TCP and UDP, if encapsulated in some tunneling stuff, is only supported by some NICs. > containers/VMs and communicate via virtual interfaces. With modern = reality we I agree. That is the motivation of the patch set in https://reviews.freebsd.org/D51639 where support for checksum offloading for the epair device is added. = This way you can send/recv packets in a jail, and the checksum is computed by the physical NIC, which is used for actually sending the packet. If the packet ends up in another jail or VM on the local host, also no = checksum is computed. The patches https://reviews.freebsd.org/D51289 https://reviews.freebsd.org/D51686 https://reviews.freebsd.org/D51688 are needed for vnet interfaces and its use by bhyve. > would probably do not do any checksumming in the stack at all, just = completely > ignore the checksum field. It would always be obligation of the NIC = driver to > care about the checksums. The existing software checksumming code = would be I agree. This is the direction of the patch you are commenting on and = the patch sets above. It would be great if you could have a look. > just a library that drivers for legacy hardware call. Local traffic = won't set > and won't check checksums neither any related flags. The above will set flags, but not do the actual computations. Best regards Michael >=20 > --=20 > Gleb Smirnoff