Proposal: per-SoC AEAD throughput probe (ChaCha20 is 2.3x AES-GCM on GK7202V300)

[bneigher]

Proposing a small AEAD throughput probe for ipctool, so the per-SoC crypto picture
becomes data instead of an assumption.

@widgetii suggested this home in OpenIPC/firmware#2344 — worth reading that thread for
the full context, but the short version follows.

Why

Hardware crypto acceleration is currently enabled for two platforms because someone
measured those two platforms. Every other SoC OpenIPC ships is an inference. And the
measurements that exist show the answer is genuinely per-chip, not per-family:

• On a gen-3 part, the crypto engine measured slower than software, so it is not
  built there.

• On gen-4 HiSilicon, the engine is a bit over 2x software (86.4 → 38.4 µs and
  87.6 → 42.0 µs per 1100-byte packet).

• On GK7202V300 (Goke, ARMv7 Cortex-A7, no ARMv8 crypto extensions, no engine
  OpenIPC builds for), I measured in software with ring 0.17 — the same backend the
  Rust TLS/QUIC stacks use — sealing 1200-byte packets:

  AEAD	throughput	per packet
  AES-128-GCM	72.8 Mbit/s	131.9 µs
  AES-256-GCM	58.7 Mbit/s	163.4 µs
  ChaCha20-Poly1305	166.0 Mbit/s	57.8 µs

  ChaCha20 is 2.3× AES-128-GCM here. NEON carries ChaCha20; AES has no hardware to
  stand on. That inverts the usual server-side ordering where AES-NI makes AES-GCM the
  obvious default.

That my software AES-128 figure (131.9 µs/1200 B) lands near the HiSilicon software
numbers on different silicon is a decent cross-check that software AES on this
generation is simply expensive — and that the interesting variable is what each chip
offers to accelerate it.

A table with a row per SoC turns "enable the engine here?" into a lookup.

What I am proposing

A probe that reports, for the chip it is running on:

• AES-128-GCM, AES-256-GCM and ChaCha20-Poly1305 seal throughput
• measured on packet-sized buffers (~1200 B), not bulk

The buffer size matters and is the one design point I would not compromise on. Bulk
throughput flatters AES on chips where per-call setup dominates, and every real consumer
here — TLS records, QUIC packets, SRTP — is packet-sized. Bulk numbers would produce a
table that looks authoritative and mispredicts the thing we care about.

Optionally, where a crypto engine exists, the same measurement through it, so the
engine-vs-software delta is directly comparable rather than inferred.

Practicalities I would want input on

1. Language/deps. My implementation is ~40 lines of Rust against ring, which is
   not what ipctool is written in. If this belongs in-tree it presumably wants C. I am
   happy to port it — but if the point is to characterise what our software stacks
   actually achieve, then measuring the library those stacks use has some value that a
   generic C implementation would lose. I do not have a strong view; you know the tree.

2. Where the numbers go. The wiki was suggested for the resulting table. Happy to
   seed it with the GK7202V300 row and whatever else people run.

3. Scope. Is this the sort of thing ipctool should carry at all, or is it better
   as a standalone one-shot binary people run once per board? It is a capability probe,
   which felt like ipctool's remit, but I would rather ask than assume.

I am not an ipctool contributor and have been around OpenIPC about three weeks, so if
the answer is "interesting, wrong repo" or "we would rather not grow the tool this way",
that is a perfectly good outcome — say so and I will just publish the numbers on the
wiki instead.

[widgetii]

Landed in 76bf277 (#187). Since this thread is where people will look before running it, here is what it actually does and — more usefully — what it does not.

What landed

ipctool cryptobench [--json] [--bytes N] [--iters N] [--no-hw]

Defaults to --bytes 1200, your design point. Output is YAML, or JSON with --json, so the wiki table can hold pasted tool output rather than hand-typed numbers. Every row carries both wall_us and cpu_us, and the whole run is tagged with chip: from getchipname() so a pasted row says which SoC it came from.

On the lab gk7205v200 (Cortex-A7, --bytes 1100, majestic stopped), µs per packet:

	wall	cpu	MB/s
AES-128-GCM	141.5	141.5	7.4
AES-256-GCM	167.7	167.6	6.3
ChaCha20-Poly1305	45.1	45.1	23.3
engine AES-CTR, one packet per ioctl	81.8	42.6	12.8
engine AES-CTR, 15 packets per ioctl	49.7	12.3	21.1
engine, 16 bytes — the per-ioctl floor	37.5	34.1	—

ChaCha20 wins by 3.14× here, so your ordering holds and is wider on this part.

The part that changes the question

You offered the crypto engine as the thing that might rescue AES-GCM. It cannot, and not because it is slow: gen-4 HiSilicon and Goke silicon has no AEAD mode at all. CHIP_AES_CCM_GCM_SUPPORT is defined for hi3569v100 alone; the block does ECB/CBC/CTR/CFB/OFB and nothing else. cryptobench establishes this by configuring a channel for AES-GCM and reporting what the driver answers, rather than by asserting it, so a part that does carry the mode will report itself instead of inheriting a hardcoded verdict.

What the engine can do is AES-CTR — the confidentiality half. The authentication half would still be GHASH on the CPU, and GHASH is the expensive half. So ChaCha20's advantage on these cameras is not a software artifact waiting to be engineered away. On this generation it is the answer.

The engine rows carry a second lesson, which is why the 16-byte row exists: nearly half the cost of a 1100-byte packet is the trip, not the cipher. A burst of 15 packets under one ioctl (OpenIPC/openhisilicon#217) cuts CPU per packet from 43 µs to 12 while wall clock barely moves. The engine is a poor bargain per packet and a good one per burst.

Limitations

It compares chips, not libraries. This is the big one, and it is a direct consequence of the "language and deps" question you raised. ipctool ships as a static musl binary, musl's dlopen is a no-op when static, and all three CI toolchains carry only libmbedcrypto.so with no .a — so the platform mbedTLS is genuinely unreachable and the primitives are implemented in-tree. They are built to be representative (runtime-generated AES T-tables and 4-bit GHASH tables, which is what mbedTLS does by default), but they are not ring and not your camera's TLS stack.

Concretely, against your GK7202V300 figures: my AES-128-GCM is roughly 15% slower than ring's, while my ChaCha20-Poly1305 is somewhat faster — different chips, but also genuinely different code. So a cryptobench row is a sound basis for "is chip A better at crypto than chip B", and a poor basis for "what will my Rust stack achieve on chip A". Holding the implementation fixed across boards is what makes the per-SoC table meaningful; it is also exactly what stops it predicting any particular library.

These are benchmark implementations, not a crypto library. src/crypto/ is table-driven and makes no constant-time claims, has no decrypt or verify path, and has had no security review. It exists to be timed. Nothing should ever lift it into a context where it protects anything.

Coverage gaps, all deliberate:

• Seal only. No open/verify direction is measured. For these three constructions the cost is close to symmetric, but it is not measured, so do not quote it as if it were.
• AES-128 and AES-256 only. AES-192 is rejected.
• 96-bit GCM nonces only — the shape every protocol here uses.
• No hash or HMAC. SRTP and TLS also spend real time in SHA-1/SHA-256, and none of it appears in these numbers. Worth knowing: earlier work measured the HiSilicon engine's hash block at roughly 5× slower than software, so the engine does not rescue that half either.
• --bytes accepts 16..2048, the engine's own per-packet ceiling. Bulk sizes are out of range by design.
• Batch depth is fixed at 15, matching the driver's limit.

Hardware coverage is HiSilicon and Goke only. The hardware half talks to /dev/cipher and nothing else. On Ingenic, SigmaStar, Novatek, Rockchip and friends you get hardware: absent and the software half still runs — which is correct for "no engine we can reach", but is not evidence that the SoC has no crypto engine. If one of those parts has an accelerator worth measuring, that is a separate probe and a welcome one.

The batched row additionally needs a driver carrying OpenIPC/openhisilicon#217; older firmware reports batched: unsupported and still measures the single-packet and floor rows.

Methodology caveats:

• Single-threaded, one core. Says nothing about how crypto scales across cores.
• Cache-warm. The loop re-seals the same buffer, so all rows are flattered equally relative to a real streamer touching cold packets. Ratios survive this; absolute MB/s is an upper bound.
• Clock-dependent. Two boards with the same SoC at different frequencies produce different rows. Pair a row with ipctool cpubench if the clock is in doubt.
• Stop majestic first. cpu_wall near 1.00 on a hardware row means the run was contending for CPU rather than sleeping on the completion interrupt — that is the tell that a number is untrustworthy, and --help says so.

A supported-AEAD engine is detected but not benchmarked. If a part accepts AES-GCM, the tool reports aead: supported, not measured and asks for an issue. No such part was available to test against, and shipping a sealing path that has never executed against real silicon would produce exactly the failure this tool exists to avoid — a fast number nobody can check. If you have an hi3569v100, please do open that issue.

On your three questions

C, in-tree — forced by the static-musl constraint above, not chosen on style. The tool generates the table rather than the wiki holding hand-typed numbers, so any row can be regenerated by whoever doubts it. Yes, it belongs here — it is a capability probe of the running chip, which is cpubench and membw's remit, and it has to run on the camera anyway to reach /dev/cipher.

For the record, "interesting, wrong repo" would have been the wrong answer. You were right that this is per-chip rather than per-family, and right that packet size was the design point not to compromise on. The 16-byte floor row — which only exists because the size is selectable — is what turned "the engine is about 2× software" into "half the cost is the syscall", and that is what justified the batched ioctl.

Please do post the GK7202V300 row from the merged tool; a second Goke data point next to the gk7205v200 one is the first real evidence about whether this is per-part or per-family.

[bneigher]

Row posted, and it answers the per-part/per-family question in a way I did not expect:
ChaCha20 is per-family, AES is per-part.

Run with master+76bf277, majestic and our agent both stopped, on a GK7202V300.

--bytes 1100, alongside your gk7205v200

	gk7202v300 (this)	gk7205v200 (yours)	delta
AES-128-GCM	172.9 µs / 6.07 MB/s	141.5 µs / 7.4 MB/s	+22% slower
AES-256-GCM	206.8 µs / 5.07 MB/s	167.7 µs / 6.3 MB/s	+23% slower
ChaCha20-Poly1305	45.5 µs / 23.05 MB/s	45.1 µs / 23.3 MB/s	+0.9%
chacha_vs_aes128	3.80×	3.14×

ChaCha20 lands within 1% across the two parts while AES is ~22% slower on mine. Both
Goke, both Cortex-A7. So the family answer is "it depends which cipher you ask about".

Full output, --bytes 1200 (the default)

cryptobench:
  packet_bytes: 1200
  iters: 20000
  software:
    aes_128_gcm:       { verified: true, wall_us: 187.622, cpu_us: 185.068, cpu_wall: 0.986, mb_per_sec: 6.10 }
    aes_256_gcm:       { verified: true, wall_us: 224.448, cpu_us: 219.941, cpu_wall: 0.980, mb_per_sec: 5.10 }
    chacha20_poly1305: { verified: true, wall_us:  48.197, cpu_us:  47.579, cpu_wall: 0.987, mb_per_sec: 23.74 }
    chacha_vs_aes128: 3.89
  hardware:
    device: absent
    note: no /dev/cipher — no cipher engine, or its module is not loaded
  chip: gk7202v300

It is not the clock. cpubench puts this part at ~841–887 MHz (dep_add 746.8 Mops,
indep_add 1416.0 Mops). I do not know yours, so I cannot normalise directly — but a
clock difference would move both ciphers together, and ChaCha20 is within 1%. Whatever
separates these two parts affects AES and leaves ChaCha20 alone.

The hypothesis I would test, offered as a hypothesis: AES here is T-table driven and so
sensitive to cache and memory latency, while the ChaCha20 path is ALU/register bound.
That would make AES the cipher that exposes per-part memory differences and ChaCha20 the
one that tracks clock. If that is right, membw alongside cryptobench should separate
the two parts roughly in proportion to the AES gap. I have not run that comparison —
one board proves nothing about the mechanism.

Hardware: absent. No /dev/cipher, no crypto modules loaded, though
/lib/modules/4.9.37/kernel/crypto exists. Consistent with Goke not being one of the
two platforms you build the engine for. Reported as the tool intends — an absent device,
not a claim about the silicon.

Confirming your library caveat, with the chip held fixed

The most useful thing I can add. You noted your in-tree primitives run ~15% slower than
ring for AES-128 and somewhat faster for ChaCha20, across different chips. I can remove
the chip variable: here are ring 0.17 and cryptobench at 1200-byte packets on this
same GK7202V300.

	ring 0.17	cryptobench in-tree	difference
AES-128-GCM	131.9 µs	187.6 µs	in-tree 42% slower
ChaCha20-Poly1305	57.8 µs	48.2 µs	in-tree 17% faster
ratio	2.28×	3.89×

The gap is larger than 15% and it points in opposite directions for the two ciphers —
which is your caveat, only stronger than stated. Even the ratio is not portable: the
same chip yields 2.28× under ring and 3.89× under cryptobench, a 1.7× disagreement
about how much ChaCha20 wins by.

Both are right about their own code. It sharpens where the line falls: a cryptobench
row is sound for ranking chips under a fixed implementation, and should not be used to
predict what any particular TLS stack will achieve — including the direction of a
ChaCha20-vs-AES decision, if the margin is narrow. On these parts the margin is not
narrow, so the conclusion survives either way; on some future part with a working AEAD
engine, it might not.

Happy to add the GK7202V300 row to the wiki table if you point me at the page and the
shape you want. And if a membw comparison would help test the cache hypothesis, say so
and I will run it here.