The modifications to ZFS can be thought of as two sets of changes: - The ZIO write pipeline - compression, checksum, RAIDZ generation, and write - Each stage starts by offloading data that was not previously offloaded - This allows for ZIOs to be offloaded at any point in these stages - Successful operations do not onload back into memory between stages - Errors cause data to be onloaded, or dropped if the copy in memory matches the offloaded copy - This might cause thrashing, but should not happen often, as the intention is for all of the stages to be offloaded, and thus not require onloading - Resilver - RAIDZ reconstruction, checksum, RAIDZ generation, and write - Because resilver is only one stage in the ZIO pipeline, data is only offloaded once at the beginning - Errors cause data to be onloaded, but will not re-offload in subsequent steps within resilver ARC compression is disabled when Z.I.A. abds are still allocated, but their contents are expected to diverge from the offloaded copy as operations are run. These opaque handles point to data that is located on an offloader. Select operations to offload zpool set zia_=on The functions that can be replaced with alternative operations are: - compression - data is offloaded and then compressed - metadata is compressed in-memory and then offloaded - decompression can be replaced, but the replacement function is not called anywhere - checksum - checksum compute and checksum error call the same function - raidz - generation - reconstruction - vdev_file - open - write - close - vdev_disk - open - invalidate - write - flush - close abd_t, raidz_row_t, and vdev_t have each been given an additional "void *_zia_handle" member. Select the provider zpool set zia_provider= 7. Implement, build, and register a provider with the DPUSM 3. acquires a handle to a DPUSM, which is then used to acquire handles to providers. to be extensible, it does not directly communicate with a fixed accelerator. Provider - a DPUSM wrapper for an accelerator's API Offload - moving data from ZFS/memory to the accelerator Onload - the opposite of offload In order for Z.I.A. Definitions: Accelerator - an entity (usually hardware) that is intended to accelerate operations Offloader - synonym of accelerator used interchangeably Data Processing Unit Services Module (DPUSM) - defines a "provider API" for accelerator vendors to set up - defines a "user API" for accelerator consumers to call - maintains list of providers and coordinates interactions between providers and consumers.
The original ZFS functions remain in the code as fallback in case the external implementation fails. Jasonlee Interface for Accelerators (Z.I.A.) The ZIO write pipeline has been modified to allow for external, alternative implementations of operations to be used. FreeBSD stable/13 amd64 (TEST): built zfs failed - stdio configure config.log make.FreeBSD main amd64 (TEST): built zfs failed - stdio configure config.log make.Fedora 35 x86_64 (TEST): built zfs failed - stdio configure config.log make.Debian 10 x86_64 (TEST): built zfs failed - stdio configure config.log make.CentOS Stream 8 x86_64 (TEST): built zfs failed - stdio configure config.log make.CentOS 9 x86_64 (TEST): built zfs failed - stdio configure config.log make.CentOS 8 x86_64 (TEST): built zfs failed - stdio configure config.log make.CentOS 7 x86_64 (TEST): built zfs failed - stdio configure config.log make.This limit could be also some tuneable, what name should I use then? Signed-off-by: Tino Reichardt Pull-request: #13695 part 1/1 Avoid all benchmarks >= 1MiB on systems, where EdonR is slower then 400 MiB/s.
Milky-zfs checksum benchmarks on systems with slow cpu The checksum benchmarking on module load may take a really long time on embedded systems with a slow cpu.
This limit is currently hardcoded, but could also be a tuneable. Avoid all benchmarks >= 1MiB on systems, where EdonR is slower then 300 MiB/s.