Just a minor nit. I do question the soundness of 'pick the fastest thing at boot time', however since this is all private interfaces, I think it's also something that could be hashed out later if we don't have a good answer right now.
It might be worth brainstorming on ways to override the implementation choice (once we have more than one) -- e.g. is it something that could be done via /etc/system, /kernel/drv/zfs.conf, etc. but not this change (i.e. I'm not suggesting holding this up for that)
This could be removed.
12668: ZFS support for vectorized algorithms on x86 (initial support)
Review Request #2560 — Created May 20, 2020 and submitted
This is a partial port of the OpenZFS code for hardware assisted (FPU) raidz handling. The current code does not provide any of the FPU support yet. Instead, this is just the refactoring to enable the plugin code so that a future change can add the actual FPU algorithms.
ZFS test suite run, including the new tests for verifying raidz generation and reconstruction still matches the existing behavior.
Addressed CR comment.
Revision 2 (+4467 -193)
Yeah -- I didn't mean to imply they needed to be addressed now -- more of a lament. It seems like the 'choose the fastest' technique could (for example) cause AVX512 implementations to be chosen on systems where using AVX512 will slow down everything else on the chip (but make the AVX512 stuff go fast).