dm vdo: add minimal IAA compression support

[AmethystCv]

Summary

This change ports the known-good intel IAA integration from the 6.11 VDO tree into the
6.11-based dm-linux branch with the smallest practical footprint.

It adds an IAA-backed compression path for VDO writes, preserves the existing
LZ4 path as the default fallback, and records the compression algorithm in the
compressed block header so that reads can choose the correct decompression path.

The goal of this patch is compatibility and correctness, not feature expansion:
it intentionally avoids bringing over the older perf, batching, benchmark, and
CPU-deflate-only code.

Motivation

A previous attempt wired crypto_acomp_compress() into VDO, but did not
reliably exercise the IAA provider at runtime.

The root cause was the CPU-local acomp context setup. In the known-good 6.11
implementation, the per-CPU IAA context is initialized on the same CPU that
holds the get_cpu_ptr() reference. This patch aligns the new code with that
model and also validates that the resolved acomp driver is actually
deflate-iaa, rather than silently running through a non-IAA provider.

What this patch changes

Write path

• Adds a per-CPU IAA acomp context in data-vio.c
• Uses deflate-iaa when iaa_enabled=1
• Initializes the per-CPU context in the same CPU-local execution context as the
  compression request, matching the working 6.11 behavior
• Verifies that the resolved crypto driver is deflate-iaa
• Falls back to the existing LZ4 path if IAA is unavailable, initialization
  fails, or compression is not effective

Read path

• Adds support for identifying IAA-compressed blocks via a compression flag in
  the compressed block header
• For IAA-marked blocks, tries IAA decompression first
• Falls back to raw zlib inflate for compatibility when IAA decompression is
  unavailable or not usable

Metadata / packing

• Extends the compressed block header with compression algorithm flags
• Records the algorithm used for each compressed block during packing
• Keeps LZ4 blocks explicitly marked as LZ4, while IAA-compressed blocks are
  marked as IAA

Module integration

• Adds a minimal iaa_enabled module parameter
• Initializes and cleans up the IAA/zlib support from dm-vdo-target.c
• Adds the required crypto/zlib Kconfig selections

What this patch does not do

This patch is intentionally minimal. It does not port:

• performance statistics
• benchmark or test programs
• batch compression support
• the older CPU-deflate write path
• extra sysfs control plumbing from the older tree

User-visible behavior

• Default behavior is unchanged unless IAA is enabled
• When iaa_enabled=1 and IAA hardware/provider is available, VDO write
  compression uses deflate-iaa
• If IAA cannot be used, VDO falls back to the existing LZ4 compression path
• Reads of IAA-marked blocks remain compatible through the zlib fallback path

How to use

Enable IAA for VDO at module load time:

modprobe dm_vdo iaa_enabled=1

Or toggle it through the module parameter interface:

echo 1 > /sys/module/dm_vdo/parameters/iaa_enabled

Notes:

- iaa_enabled=1 enables the IAA path, but actual use still depends on the
  deflate-iaa provider being available
- If IAA is not available, writes fall back to LZ4 and reads remain compatible
- about how to enable IAA :dm-linux/Documentation/driver-api/crypto/iaa/iaa-crypto.rst

## Testing

- Verified on the 6.11-based dm-linux codebase
- Verified that this version correctly uses the IAA compression path on the
  target test system
- Verified compatibility of the IAA-marked read path, including zlib fallback
- Verified that existing LZ4 fallback behavior is preserved
### FIO performance comparison
A basic fio comparison was also run between the LZ4 baseline and this IAA-based
implementation using the results under:

Test matrix:
- 72/72 cases completed successfully
- I/O types: `write`, `read`, `randwrite`, `randread`
- block sizes: `4K`, `8K`, `16K`, `32K`, `64K`, `128K`
- job counts: `1`, `8`, `16`
- warmup: `30s`
- runtime: `60s`
- fio data compressibility: `60%`

Observed results versus the VDO-LZ4 baseline:
- Sequential write: average bandwidth change `+0.56%`, median `+0.91%`
- Random write: average bandwidth change `+0.36%`, median `+0.88%`
- Sequential read: average bandwidth change `-2.61%`
- Random read: average bandwidth change `-2.02%`

Write-path highlights:
- IAA improved bandwidth in `13/18` sequential-write cases
- IAA improved bandwidth in `10/18` random-write cases
- The strongest write-path gain in this run was:
  - sequential write, `64K`, `16 jobs`: `1415.4 -> 1499.9 MB/s` (`+5.97%`)
- Another representative gain:
  - random write, `64K`, `8 jobs`: `1444.1 -> 1519.4 MB/s` (`+5.21%`)
 
These fio results are intended as a sanity/performance reference for this patch,
not as a full compression benchmark. The main conclusion is that the minimal IAA
integration behaves correctly and shows small but repeatable write-side gains in
this test matrix without introducing functional regressions.

## Review notes

The patch is intentionally localized to:

- data-vio.c for IAA/zlib compression and decompression logic
- packer.[ch] for algorithm tagging in compressed block metadata
- data-vio.h for per-fragment algorithm tracking
- dm-vdo-target.c for minimal module parameter and lifecycle wiring
- Kconfig for required crypto/zlib dependencies

[lorelei-sakai]

This repository does not accept public submissions. If you wish to submit a change to dm-vdo, you should do so by sending it the device-mapper mailing list (dm-devel@lists.linux.dev) for discussion.

When you do, though, I would also advise you to describe the feature you are trying to add in more detail, and provide references to the "known-good intel IAA integration from the 6.11 VDO tree" that you are trying to integrate, because, as far as I can tell, no such feature exists, or has ever existed.