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 244A7C48BF6 for ; Mon, 26 Feb 2024 18:35:36 +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=ixIFXd/zGIFIV9IXdfLaPjNolb0tV+nG/5uMrALXUa4=; b=YUDkPFVfWsAtmx ixRTHPpb26MWR0M4+WOSawLxhP+KkaSMogvrYJ2gEPrYToXPQ6JUgo1PKbYuECjqSMfg4S55brmhD h532YK/Yop/koe4zrqgbYDjYFr/2M1DZhHWfg5i8loPuYINe8/RsWfseq+cl2Dh5rCJXn2X/NIOy3 hynccuHYR21GO4OEh7tzQFl6SvPFfOmAhjoD+0OMoR5bEXPjeqBJxLkWx3E0tdpSIeFvNjmn+/jdw ZvXv9Ce4BJRoHlS5kiihoblRxaoq3Zy5357x7KMcTNAXsA2OBR0re1iuMOy3YgoDUfknQpBROUTr1 7ZWF6yFaq51z7OlO5Hcw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1refp0-00000002CaL-3DS2; Mon, 26 Feb 2024 18:35:26 +0000 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1refow-00000002CZi-3m2E for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 18:35:24 +0000 Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1dc418fa351so17732005ad.1 for ; Mon, 26 Feb 2024 10:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1708972522; x=1709577322; 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=hw6lDBVvZVaoT5voqNH6HBuUGCB84uuT6JNYSXYgCm4=; b=gqVeru6rEfehEEbXAYE04DwfR+OtlU6Y4THt6hkK9Drss9aPhTqXBwYZ9W4zrhCQYg zOrbJYYOBNQyX11A+q/7QsIm3FpZLqWPI9tqjNhhbwV8jSLMAPJMS9zaVmOKCdzAujuQ gHDvsXGL5Z7mx9qXhNb6rY83WjSJUGBqOC7IQcnZPj2aM25w3LVDQ1JCP8q1gffJ6YKE SQYN6Ncexogwc1SK5mDxk1/7NDQ11EUXPtD5IUXvWcq3Xv72634HbPx38Zs8NwQ1XmlU YiZbiN9QZfKIi64ueW8aReAs89OBAix2o6O89Ln2bXqSjr6XuxnNkDESvk7Lewto1zBS mdjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708972522; x=1709577322; 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=hw6lDBVvZVaoT5voqNH6HBuUGCB84uuT6JNYSXYgCm4=; b=VtUnp/nMYaPwwgDjk1NXAIuplrxkwTddYWAidYIuXmaT3DIbpHDfkrteXE6Udmn0tv HlMNeBNmHk9v48DR5F7UMY9BuYq4861jQnQlNhdLVDcFqiZRaHPGwGQ0w0TbOlR2Lqg6 OEImDb0UAt6FUbZmwHx+EnITEdgdadcAoR/tpKJ0ZwuMw+xZ6w4ZmSblSI8HJltrlaP0 n0hycyasPJZr6XRYX+j54IxIDAZQPHzcLApK6gMjEOH/vI1s7fWHqiyGUEeMOdOEb0lL f/0fI0jFsqm6LR49HkQau/0GS+XxnovbrZGw6z9C7pW4kLLAsBWEDzvGcWyVeicA1CzY ESkw== X-Forwarded-Encrypted: i=1; AJvYcCUFJXO4O7i77QXcZGi1Igx5YrkDBh/rCWGM1SkZnosQOR1VL7lJ1l87Wc0ryvFN5AvbQRpzteXO4e6Qb7JLAeS0m57jmi4bMYtc7vooI+wBBSynRtU= X-Gm-Message-State: AOJu0YwShOZnOFeASecC208PZCaKQFKA4EyLzIIzoAzQZIVQ5yyqmC9F Fg8ELXKoBM+cHaZi5j4qF6e1QDEw0tK4eLHQG63/6l9nA9SDSyTX653dKPPLF6M= X-Google-Smtp-Source: AGHT+IFLhP5psYVyjx40hbzYLeS2d/I0I4J4aVqBaUBTza9Iak7Uinrj5RB0XUTFvA/Q90Nz44eSxQ== X-Received: by 2002:a17:902:d548:b0:1dc:b008:f678 with SMTP id z8-20020a170902d54800b001dcb008f678mr2012067plf.18.1708972522069; Mon, 26 Feb 2024 10:35:22 -0800 (PST) Received: from ghost ([50.213.54.97]) by smtp.gmail.com with ESMTPSA id d20-20020a170903209400b001db83d42322sm2437plc.185.2024.02.26.10.35.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 10:35:21 -0800 (PST) Date: Mon, 26 Feb 2024 10:35:18 -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_103523_159090_5579A281 X-CRM114-Status: GOOD ( 33.60 ) 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 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 proper= ly > > > > aligning the IP header, which were causing failures on architectures > > > > 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 alignm= ent. > > > = > > > Shouldn't ip_fast_csum() and csum_ipv6_magic() work for any alignment= as > > > well ? I would expect it, I see no comment in arm code which explicits > > > 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 source = 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 able > > to handle, not what they are optimized for. If byte and/or half word al= ignments > > are expected to be supported, there is still architecture code which wo= uld > > have to be fixed. Unaligned accesses are known to fail on hppa64/parisc= 64 > > and on sh4, for example. If unaligned accesses are expected to be handl= ed, > > it would probably make sense to add a separate test case, though, to cl= arify > > that the test fails due to alignment issues, not due to input parameter= s. > = > 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. - Charlie > = > There's a lot to be researched here! > = > -- = > 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