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 5F5AFC48BF6 for ; Mon, 26 Feb 2024 19:19:34 +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=m3ZQt41vNtrYx6lZZqOnSubKkGo0BahwzVX7W0/RUJg=; b=h1AzN90YoUXxMU KUrniChGqGOoMEaMM0kQlcHoqUwW3C9u1iH6DygkIwFIgbIv1/j/3D9m/x7Mxv3JQqJmkhycConRp o4GTppkZPULVBVUPqNJ7GCGVsGlCeY/G+Dw5tURiJ02WiCGLo2BnTQI+/8Cp4Ju0DziJBTwS1QwTO GEPvGiQZKhhKWrACgtIejlvN1RG7PtWjrWWwXMovkXzCYFNy6VwDwSDBr9tpPQTr26GqMr0AruG2O Yx2SfMNjN6mfvFPK+unLCbbOxZ12jSToWG0Zh/RQVWFD92ZYlMfPT3nNnrWdexQ8/ZGRtSTCu+ak1 WBgjldWvMgqyKkCi2J6A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1regVY-00000002MCp-38wt; Mon, 26 Feb 2024 19:19:24 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1regVV-00000002MC4-2iGN for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 19:19:23 +0000 Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-29ab7073dd2so974445a91.0 for ; Mon, 26 Feb 2024 11:19:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1708975160; x=1709579960; darn=lists.infradead.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=LP96tCONgQZzLKOt6HJu425nt0R69w5f62QxpSwr1Ws=; b=iOyoV7NvUZw7uDgA2VuMsD3o771hDutp30CmfHrKv+vJY7IwDEnTSYJialpM3gE1L3 I7cNRuFv1zsDF0t3OzNjMDNX+6ME9BJc/4tfzWH1XPUZa/4dkz5gLSDR0Qd/qqflO/2C fPArttWmLClN2X4Y1CkwPMv8i2Iu0FOth2oa3P6xkIdoV5qQN2j5cRkI/k8CoefMjxTs fOF+Dt8N+XEgBoJFAIOKu4Kf7kAF1nj+gr+x4bpa97n23MEqiYj4zshXYeR5Ij6swM+J fqiBDhDVxUwINQGQQFdSLSfJxXeKXBi7u+kEx9mDJQyXcQpCmW91oiFHgvmfZhiU+5qV sEHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708975160; x=1709579960; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LP96tCONgQZzLKOt6HJu425nt0R69w5f62QxpSwr1Ws=; b=eNsQt0xdlWAlwdhNLJaof9EclWXGATPDubiQ4qoQ1xw4nMH/8tZd+xLUGI/uv+nAAb vodwCTA36bUQAmjCgdJXH+o3nUZqVP/oCDm7+xr9da8Niymry8rvvTUghiTSNNEJMMks XHC4Td/qkmxP4pye/cxnkx0+mfavdqZ7XYErktHQ1HcTO+8gLLiXQiwdwKbfyUr7ny29 9BV4jGGd/uoraQnW7ldRaE8ezJGCkQgTWK/ThrJq7gr6ssD+zX+dZfZaJph4OgSjLCTK kdREJQ7AR4ePPp8UafVvfrFUGErYlQyhDHTYONY9YHGJU1GgW55fSljWqs3j97Umu8li 7yGg== X-Forwarded-Encrypted: i=1; AJvYcCVuj2TAq1N1wU7QbkoJ/o03w/jT1XycGYXaYNIvBsNYv7o5wk7Q+4FekgqH0cWt3x4eRu0DoG5wuiSLWtabK3x7Ff7BKglo5ctDeEq2qpsFnuLdrig= X-Gm-Message-State: AOJu0YxdXFvqw+2HGuhJSJpZqQJrsyP5rvgxz4a40L2tRhPTSccd32pi nLI/XNdkQ8LTl9bVhUZoDe+f1VD8ps6PBLv8a80ix0F2ScpDw8PjEJwH9UQHAjJpKcarH28XNTt pyq4= X-Google-Smtp-Source: AGHT+IGqrOoB2svzJRunxD6HlWQbtvuz8cc1bx8/K5x6DzRWLxfXhdCGOVrRmpAHwF2Zg1GTs1ZMPg== X-Received: by 2002:a17:90a:ee8a:b0:299:4d91:c8f6 with SMTP id i10-20020a17090aee8a00b002994d91c8f6mr5552927pjz.35.1708975159886; Mon, 26 Feb 2024 11:19:19 -0800 (PST) Received: from ghost ([50.213.54.97]) by smtp.gmail.com with ESMTPSA id se13-20020a17090b518d00b00299b31de43esm6883869pjb.45.2024.02.26.11.19.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 11:19:19 -0800 (PST) Date: Mon, 26 Feb 2024 11:19:16 -0800 From: Charlie Jenkins To: "Russell King (Oracle)" 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_111921_715294_0C2879E9 X-CRM114-Status: GOOD ( 37.55 ) 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 07:06:46PM +0000, Russell King (Oracle) wrote: > 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 pr= operly > > > > > > aligning the IP header, which were causing failures on architec= tures > > > > > > that do not support misaligned accesses like some ARM platforms= . To > > > > > > solve this, align the data along (14 + NET_IP_ALIGN) bytes whic= h 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 al= ignment. > > > > > = > > > > > Shouldn't ip_fast_csum() and csum_ipv6_magic() work for any align= ment as > > > > > well ? I would expect it, I see no comment in arm code which expl= icits > > > > > 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 sou= rce or > > > > > destination address, isn't it enough to perform a 32 bits alignme= nt ? > > > > > = > > > > = > > > > It isn't just arm. > > > > = > > > > Question should be what alignments the functions are supposed to be= able > > > > to handle, not what they are optimized for. If byte and/or half wor= d alignments > > > > are expected to be supported, there is still architecture code whic= h would > > > > have to be fixed. Unaligned accesses are known to fail on hppa64/pa= risc64 > > > > and on sh4, for example. If unaligned accesses are expected to be h= andled, > > > > it would probably make sense to add a separate test case, though, t= o clarify > > > > that the test fails due to alignment issues, not due to input param= eters. > > > = > > > 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. What alignment can be relied on by a test case? - Charlie > = > -- = > 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