From nobody Wed Aug 6 22:35:37 2025 X-Original-To: dev-commits-src-main@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 4by4rD2k5Cz64Jfy; Wed, 06 Aug 2025 22:35:40 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4by4rD11Lcz3X89; Wed, 06 Aug 2025 22:35:40 +0000 (UTC) (envelope-from glebius@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1754519740; 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: in-reply-to:in-reply-to:references:references; bh=2FXKLfKTiIlBkOfWkwwt2rOTdKfCOaXHudbRl2mT43c=; b=nE486xCtqAekQVSuJKXerWGAailibeVAgrRPDbDr0s62sRm6mG6fTascH6BXLm15oDvP0e HlJdzYuFAe0KbkVsmC+Rkrcp61q9afE6i2pw9AZUziEFBzzJoc03xmas+FVzHOeOllZVnW yVZFAJ2SsqmBxfIjI7qmUWhtHSpBcNeyJZeoZZaKu88qiBsAvibO95dZiDDNPtSwr+zfIO kzQY1yVTAagdZDjKCUQxtNNhmZEjF1kEIo3Xzr+V0w5dWZRufyo4Q+kefWcy5WQ4L39fyt YwBJY3doAfQlgsJuVOaucvv32Xbhx7HFbyImovX8d/trnvKpyooOGzKBwM2HcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1754519740; 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: in-reply-to:in-reply-to:references:references; bh=2FXKLfKTiIlBkOfWkwwt2rOTdKfCOaXHudbRl2mT43c=; b=Se8eCngoDH+BmPdcqTt8XTw+BzZcwE0d9MqKitDC5TFppPhcwoM+0Wt740sBbJMh6CYAc1 kTuVCd6deePr+SZ4U/41HBf3hJYklovKWFiLoxGdQCG/bWHp2Wd1p4txpnJPXiE41L8fzL gABrZPTS+VHvbBPYclcq/2zOaYdQmd1tCJcSlJCSsZg41H1cWMUwRLrWMZJ8UI/NE7Osok SKmHiou+aLCTNT6lHJ8H/oH5hUjroEgIPNWwZ+2lfBHgvBsnUzLspfcuUt6AyV17+sUWXM dt8MZvUjlF7vGIwM48SH1fJKosNR65RA/Ntw5R+4YhS+qwbiRacj8/cg+3URBA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1754519740; a=rsa-sha256; cv=none; b=yO5bmNL6vp0Nkri+Inr+g9qMfW/k47ZkxRcnZ+h1OGR6AauI2JwxHV9/3Yrq1y7AZ0/1id kFr8QhM7EzUc/o6dqAeFWC6d0JcVrE1kJSzk0G2YyZpCUku1thK5aRho8BszrtSXVOn+0s LTOAOMqtdeNTkmzFlw3NX+Cc7PLGAmMSe1C/yN/pEVrwPtqLARdaVyctXpPzgTt65zqzTp FGeSYF1DBSJ1GX2kp2H8lYYudpWHtZx40KAq+3LDBtwkBAOHLCzf1+we2CVjhszMTufUCx 6+d8nH2zcHuve4SvNyYXdDd2Q84dDoQqACBtsoMcd9p/ISryurgRE2S7Esy5Fg== Received: from cell.glebi.us (glebi.us [162.251.186.162]) (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 did not present a certificate) (Authenticated sender: glebius) by smtp.freebsd.org (Postfix) with ESMTPSA id 4by4rC3DFxzR0k; Wed, 06 Aug 2025 22:35:39 +0000 (UTC) (envelope-from glebius@freebsd.org) Date: Wed, 6 Aug 2025 15:35:37 -0700 From: Gleb Smirnoff To: Michael Tuexen Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: bcb298fa9e23 - main - sctp, tcp, udp: improve deferred computation of checksums Message-ID: References: <202508010817.5718HZM6067171@gitrepo.freebsd.org> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-main@freebsd.org Sender: owner-dev-commits-src-main@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202508010817.5718HZM6067171@gitrepo.freebsd.org> Michael, 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. Not a request for any action, but a general comment on the topic. Imagine we are developing an IP stack from scratch for modern computers. Most NICs do hardware checksumming, large fraction of installations run in containers/VMs and communicate via virtual interfaces. With modern reality we 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 just a library that drivers for legacy hardware call. Local traffic won't set and won't check checksums neither any related flags. -- Gleb Smirnoff