Re: [PATCH 1/2] lib/crc: loongarch: Use hardware unaligned load in CRC32(C) loops

["Wentao Guan" <guanwentao@uniontech.com>]

Hi,

> > Hi Eric,
> >
> > > On Mon, Oct 12, 2026 at 02:43:47PM +0800, Huacai Chen wrote: 
> > > > Yes, we considered modifying {get,put}_unaligned_* globally. But it is
> > > > not arch-specific code and we have no way to override it.
> > > >
> > > > On the other hand, the byte-to-byte {get,put}_unaligned_* is always
> > > > correct, we are free to only optimise the hot path (like crc32 code). 
> > >
> > > The unaligned access macros are used in lots of other
> > > performance-critical code.  Hacks in random places don't scale. 
> > Agree, from their side, they thought may like: the change is minimal?
> > My thought like what other arch did, use alternative to patch the {get,put}_unaligned_*?
> >
> > > > > > Since loongarch made the incorrect decision to not specify unaligned
> > > > > > access unconditionally, similar to RISC-V it can be worked around only
> > > > > > by overriding that in the kconfig.  For loongarch that appears that
> > > > > > already be implemented; just unset CONFIG_ARCH_STRICT_ALIGN when you
> > > > > > know the kernel will run only on CPUs that have fixed this bug. 
> > > > > I think that we have the use cases to provide the general kernel instead of the two kernel with
> > > > > different config, so the image increase will be tolerated. 
> > > > Yes, the default configuration is to keep CONFIG_ARCH_STRICT_ALIGN set
> > > > for single kernel binary. 
> > >
> > > So don't do that.  It does not work for divergent unaligned access
> > > support, as the other architectures have learned long ago. 
> >
> > From RISC-V workaround learn, their model is different,
> > they want to default unaligned access, and trap and emulate the access.
> 
> Which is entirely broken from a performance point of view.
> Especially since some system hide the emulation from the kernel.
Emmm, I don`t know if it existed in LoongArch system...

> >
> > This LoongArch model is point to default safely aligned access,
> > after detected the unaligned access support, next to use the unaligned to speed up.
> > Or did anything I missing?
> 
> There are three cases:
> 1) Unaligned accesses fault and must be avoided.
> 2) Unaligned accesses are executed by the cpu but take a small number
>    of extra cycles.
> 3) Unaligned accesses are executed by the cpu and are (almost always)
>    free.
> For (2) it is still worth aligning buffers.
> x86 is pretty much in camp (3) - I suspect it uses byte-enables on a 64 byte
> wide interface to the cache.
> 
> If you align buffers you don't have to worry about things like
> 'word at a time strlen()' running off the end of a page.
Agreed, as I known some hours ago for unaligned access existed in LoongArch
desktop/server chip, so for me now is not motivated to do the complexed work.

Thanks
Wentao Guan