apache / apache/trafficserver

Heads-up: riscv64 build fails at `ink_queue.h` "unsupported processor" (no RISC-V freelist case)

Open
#13,555 3 comments 0 reactions 3 assignees Claimed by @phongn View on GitHub
Build Support
Dominant language
C++
Stars
2k
Forks
874
Avg merge
6d 15h
Merged PRs (30d)
46

Description

G'day ATS team,

First off — thank you for Traffic Server. We're big fans of the project, and we've been working on packaging **ATS 10** for [Nixpkgs](https://github.com/NixOS/nixpkgs) (the package set behind NixOS). Work-in-progress PR here: https://github.com/NixOS/nixpkgs/pull/474177

While testing that package across a few architectures, we stumbled onto a small issue we thought was worth flagging — **not urgent at all**, purely a friendly heads-up for if/when RISC-V is on your radar.

## What we saw

x86_64 and aarch64 build and run great (we tested aarch64 natively on real hardware). On **riscv64** the build stops at:

```
include/tscore/ink_queue.h:177:2: error: #error "unsupported processor"
```

This reproduces both cross-compiling to riscv64 and building natively on a riscv64 board (SpacemiT K1). It's present on `master` as well as the `10.2.0-rc1` tag.

## Why it happens

The lock-free freelist head in [`include/tscore/ink_queue.h`](https://github.com/apache/trafficserver/blob/master/include/tscore/ink_queue.h) chooses one of two strategies:

1. a **generic path** when the toolchain has a lock-free 128-bit CAS — `#elif TS_HAS_128BIT_CAS` (line ~127), or
2. an **architecture-specific pointer-tagging** layout, hand-coded only for x86_64 (line ~133) and aarch64 (line ~157); everything else hits the `#else` → `#error` (line ~177).

`TS_HAS_128BIT_CAS` is decided by [`cmake/Check128BitCas.cmake`](https://github.com/apache/trafficserver/blob/master/cmake/Check128BitCas.cmake), which compiles:

```c
int main(void) {
__int128_t x = 0;
return __sync_bool_compare_and_swap(&x, 0, 10);
}
```

On riscv64 there's no inline lock-free 128-bit CAS, so this lowers to a libatomic call and the probe fails to compile/link; the fallback retry uses `-mcx16`, which is x86-only. So `TS_HAS_128BIT_CAS` ends up **off**, and with no riscv64 branch in `FREELIST_POINTER`, the build falls through to the `#error`.

## Possible directions (just ideas — you know the code far better than we do)

- Add a **riscv64 case** to the `FREELIST_POINTER` / `FREELIST_VERSION` / `SET_FREELIST_POINTER_VERSION` macros, analogous to the existing aarch64 block. One thing to watch: riscv64 Linux virtual-address width isn't fixed (Sv39 / Sv48 / Sv57), so the number of spare high bits available for the version counter varies — the aarch64 block assumes a 52-bit VA, whereas a conservative riscv64 layout might need fewer version bits.
- Or allow the generic `TS_HAS_128BIT_CAS` path on riscv64 (e.g. via libatomic), accepting that 128-bit CAS there may not be lock-free without the Zacas extension.

Either way, we didn't want to presume the right approach — mostly just wanted to put this on your radar.

## Offer to help

We have a riscv64 board (SpacemiT K1) and a cross-compile setup, so we're very happy to **test any patch** on real RISC-V hardware if that's useful.

Thanks again for all the work on Traffic Server!

### Environment
- ATS: `10.2.0-rc1` tag and `master`
- Arch: `riscv64` (reproduced cross-compiling on x86_64 and natively on a SpacemiT K1)
- Toolchain: GCC (via Nixpkgs)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.