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 E65E0C5478C for ; Mon, 26 Feb 2024 22:34:19 +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:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:CC:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zJLt1Jch0ampBleLCaNuiqFs5HFP379zP97T3LZo79s=; b=CVTSUd/ACav/IN 08znWVlSjjosZlrZtqyAx+nCnxVIQVyiABgvd+HylAKK9Om7S/xAZ8bXvJDwyJKHCE0El6PAZcRIY irlnfnEBW5jP0rvXCHO/M626/qrpTCJ+JCfWFCJj4RSeumYgXHbHMIXNxcqGYVRaL0rYhVX5cGWeu sV4Y5JS9auOnYvr+W9A8IF6//eACwJvLoQFoe0jhX3/aB+J1FVGOcncsGo3xk6ZBOe62CCf517Lk3 nv7WtMZS0GrJiWSXl6SmAsnVbcQEjAlz4PX8Ys+eXvp4cz5q+lK0sbWUW/AADeWLpV9JmlFIhx4Co tq7qPiEb2Nag/wV18Y0Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rejXy-00000002rO9-25Sc; Mon, 26 Feb 2024 22:34:06 +0000 Received: from eu-smtp-delivery-151.mimecast.com ([185.58.86.151]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rejXv-00000002rNZ-2WsM for linux-arm-kernel@lists.infradead.org; Mon, 26 Feb 2024 22:34:05 +0000 Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-23-WxwTNdofNyCIwID63HDNlQ-1; Mon, 26 Feb 2024 22:33:58 +0000 X-MC-Unique: WxwTNdofNyCIwID63HDNlQ-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 26 Feb 2024 22:33:56 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Mon, 26 Feb 2024 22:33:56 +0000 From: David Laight To: 'Russell King' , Charlie Jenkins CC: Guenter Roeck , Christophe Leroy , 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 Thread-Topic: [PATCH v10] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6_magic tests Thread-Index: AQHaaOb3nOScRpPJiESuqwXNhBxv4rEdMNJg Date: Mon, 26 Feb 2024 22:33:56 +0000 Message-ID: References: <20240223-fix_sparse_errors_checksum_tests-v10-1-b6a45914b7d8@rivosinc.com> <7ae930a7-3b10-4470-94ee-89cb650b3349@csgroup.eu> In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240226_143403_955347_80D80928 X-CRM114-Status: GOOD ( 10.95 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org ... > 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. I'm sure I've seen code that would realign IP headers to a 4 byte boundary before processing them - but that might not have been in Linux. I'm also sure there are cpu which will fault double length misaligned memory transfers - which might be used to marginally speed up code. Assuming more than 4 byte alignment for the IP header is likely 'wishful thinking'. There is plenty of ethernet hardware that can only write frames to even boundaries and plenty of cpu that fault misaligned accesses. There are even cases of both on the same silicon die. You also pretty much never want a fault handler to fixup misaligned ethernet frames (or really anything else for that matter). It is always going to be better to check in the code itself. x86 has just made people 'sloppy' :-) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel