From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 892BCC5478C for ; Mon, 26 Feb 2024 19:07:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=84pVkBYru0kksypLUzAKsmROCJshyoH4aPqctiszcU4=; b=IlGGNQemMOWO8k 677uKi01X30+rFhut6nqoVX7YHkNvo38PkFLPDsnMPpSeK0igLNli1XSroVs57nZ377xollAnRKav bTvzJiDqHY48FRq+u9IORSDdCWQ5djy7Vy7cHHw/vfQIBHaZDbvZwYLtftnipnXb5CnfEjmuJn6yi DVKyDI9Gq+xyuh/oqwVGVUS1uTQnwv5Ih1+FdcVxmQEOStMT+DLURTl1UanDGdlxQWUGbX2DGU99s 28bfZHwLdeOGBrw0VX9KmTP7HCln61SCE6J07Ak4Z4WBtPO2YFLJMfQ9Gzju8BIM2Z+cTggsoebIw z4x2jd5dmoJUa1KPl6BA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1regJq-00000002J2y-2WOi; Mon, 26 Feb 2024 19:07:18 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1regJn-00000002Iyb-1Hye for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 19:07:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=p9KjOlu0+TEJffXffYs7C37fc+zygG+gBQDwUHyWubM=; b=MOK4PN3Og8rk6JU6g/g8QfsZhX mALDPkPGKkCfHWrsMRhTPcRVXeI+jhwqbEbrajU8tBCo1QmNgg4/jTfWwR8wjcFvDFUNNSEIaleJt uLiKY21HevkbnEgWwEQ+Kb4na7jJjlsNq5lcqNguwVVSmFRf618UvykUgUcxcGOnHfmQNRomPhIjB BCqP6A3BQEyebPbZG/NKGATVluIzPC9px/m/Y7O1reqVIzSnP5E7WgZ1D1cg6rIJp0/MOrDevKgXv uDcUt/n1GpuYVldBbIbJ8juegUuJVgoqRCAGAQPQwefpH/GZvxo8sYARgf35T+dFNxlpsR9RUv8gy nP4T7rRQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:37538) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1regJO-0004mT-08; Mon, 26 Feb 2024 19:06:50 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1regJK-0006fG-SC; Mon, 26 Feb 2024 19:06:46 +0000 Date: Mon, 26 Feb 2024 19:06:46 +0000 From: "Russell King (Oracle)" To: Charlie Jenkins Cc: Guenter Roeck , Christophe Leroy , David Laight , Palmer Dabbelt , Andrew Morton , Helge Deller , "James E.J. Bottomley" , Parisc List , Arnd Bergmann , "linux-kernel@vger.kernel.org" , Palmer Dabbelt , Linux ARM Subject: Re: [PATCH v10] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests Message-ID: References: <20240223-fix_sparse_errors_checksum_tests-v10-1-b6a45914b7d8@rivosinc.com> <7ae930a7-3b10-4470-94ee-89cb650b3349@csgroup.eu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240226_110715_374734_077E0FFF X-CRM114-Status: GOOD ( 33.92 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Feb 26, 2024 at 10:35:18AM -0800, Charlie Jenkins wrote: > On Mon, Feb 26, 2024 at 05:50:57PM +0000, Russell King (Oracle) wrote: > > On Mon, Feb 26, 2024 at 08:44:29AM -0800, Guenter Roeck wrote: > > > On 2/26/24 03:34, Christophe Leroy wrote: > > > > = > > > > = > > > > Le 23/02/2024 =E0 23:11, Charlie Jenkins a =E9crit=A0: > > > > > The test cases for ip_fast_csum and csum_ipv6_magic were not prop= erly > > > > > aligning the IP header, which were causing failures on architectu= res > > > > > that do not support misaligned accesses like some ARM platforms. = To > > > > > solve this, align the data along (14 + NET_IP_ALIGN) bytes which = is the > > > > > standard alignment of an IP header and must be supported by the > > > > > architecture. > > > > = > > > > I'm still wondering what we are really trying to fix here. > > > > = > > > > All other tests are explicitely testing that it works with any alig= nment. > > > > = > > > > Shouldn't ip_fast_csum() and csum_ipv6_magic() work for any alignme= nt as > > > > well ? I would expect it, I see no comment in arm code which explic= its > > > > that assumption around those functions. > > > > = > > > > Isn't the problem only the following line, because csum_offset is > > > > unaligned ? > > > > = > > > > csum =3D *(__wsum *)(random_buf + i + csum_offset); > > > > = > > > > Otherwise, if there really is an alignment issue for the IPv6 sourc= e or > > > > destination address, isn't it enough to perform a 32 bits alignment= ? > > > > = > > > = > > > It isn't just arm. > > > = > > > Question should be what alignments the functions are supposed to be a= ble > > > to handle, not what they are optimized for. If byte and/or half word = alignments > > > are expected to be supported, there is still architecture code which = would > > > have to be fixed. Unaligned accesses are known to fail on hppa64/pari= sc64 > > > and on sh4, for example. If unaligned accesses are expected to be han= dled, > > > it would probably make sense to add a separate test case, though, to = clarify > > > that the test fails due to alignment issues, not due to input paramet= ers. > > = > > It's network driver dependent. Most network drivers receive packets > > to the offset defined by NET_IP_ALIGN (which is normally 2) which > > has the effect of "mis-aligning" the ethernet header, but aligning > > the IP header. > > = > > Whether drivers do that is up to drivers (and their capabilities). > > Some network drivers can not do this kind of alignment, so there are > > cases where the received packets aren't offset by two bytes, leading > > to the IP header being aligned to an odd 16-bit word rather than an > > even 16-bit word (and thus 32-bit aligned.) > > = > > Then you have the possibility of other headers between the ethernet > > and IP header - not only things like VLANs, but also possibly DSA > > headers (for switches) and how big those are. > = > Those additional combinations can be supported by future test cases, > but the goal of this patch was simply to have basic testing for these > functions. The NET_IP_ALIGN offset is what the kernel defines to be > supported, so that is the test case I went for. I think you misunderstand. "NET_IP_ALIGN offset is what the kernel defines to be supported" is a gross misinterpretation. It is not "defined to be supported" at all. It is the _preferred_ alignment nothing more, nothing less. -- = RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel