On Wed, Oct 25, 2023 at 10:52:22PM +0200, Arnd Bergmann wrote: > 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 Thank you for pointing that out, I had not realized that macro existed. Since riscv keeps NET_IP_ALIGN at 0 it should be expected that ip_fast_csum is only called with 32-bit aligned addresses. I will update the comment and refer to that macro. riscv supports misaligned accesses but there are no guarantees of speed. - Charlie
