Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1048-g9229b632c5-fm-20231019.001-g9229b632
MIME-Version: 1.0
Message-Id: <059f17e6-e240-40fa-8742-7844ad3b3502@app.fastmail.com>
In-Reply-To: <ZTl8gauEst2NGrw6@ghost>
References: <20230919-optimize_checksum-v7-0-06c7d0ddd5d6@rivosinc.com>
 <20230919-optimize_checksum-v7-2-06c7d0ddd5d6@rivosinc.com>
 <DM8PR11MB575134C301E7E17E72281CFAB8DEA@DM8PR11MB5751.namprd11.prod.outlook.com>
 <ZTl8gauEst2NGrw6@ghost>
Date:   Wed, 25 Oct 2023 22:52:22 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Charlie Jenkins" <charlie@rivosinc.com>,
        "Wang, Xiao W" <xiao.w.wang@intel.com>
Cc:     Linux-Arch <linux-arch@vger.kernel.org>,
        "Albert Ou" <aou@eecs.berkeley.edu>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Conor Dooley" <conor@kernel.org>,
        "David Laight" <David.Laight@aculab.com>,
        "Palmer Dabbelt" <palmer@dabbelt.com>,
        "Paul Walmsley" <paul.walmsley@sifive.com>,
        "linux-riscv@lists.infradead.org" <linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v7 2/4] riscv: Checksum header
Content-Type: text/plain
Precedence: bulk

On Wed, Oct 25, 2023, at 22:37, Charlie Jenkins wrote:
> On Wed, Oct 25, 2023 at 06:50:05AM +0000, Wang, Xiao W wrote:

>> > +
>> > +/*
>> > + * Quickly compute an IP checksum with the assumption that IPv4 headers
>> > will
>> > + * always be in multiples of 32-bits, and have an ihl of at least 5.
>> > + * @ihl is the number of 32 bit segments and must be greater than or equal
>> > to 5.
>> > + * @iph is assumed to be word aligned.
>> 
>> Not sure if the assumption is always true. It looks the implementation in "lib/checksum.c" doesn't take this assumption.
>> The ip header can comes after a 14-Byte ether header, which may start from a word-aligned or DMA friendly address.
>
> While lib/checksum.c does not make this assumption, other architectures
> (x86, ARM, powerpc, mips, arc) do make this assumption. Architectures
> seem to only align the header on a word boundary in do_csum. I worry
> that the benefit of aligning iph in this "fast" csum function would
> disproportionately impact hardware that has fast misaligned accesses.

Most architectures set NET_IP_ALIGN to '2', which is intended
to have the IP header at a 32-bit aligned address, though
some other targets don't bother:

arch/arm64/include/asm/processor.h:#define NET_IP_ALIGN 0
arch/powerpc/include/asm/processor.h:#define NET_IP_ALIGN       0
arch/x86/include/asm/processor.h:#define NET_IP_ALIGN   0
include/linux/skbuff.h:#define NET_IP_ALIGN     2

I think it's considered a driver bug if an SKB ends up
with a misaligned IP header, but it's also something that
some of the more obscure drivers get wrong.

    Arnd