randomizedcoder opened a new issue, #13555:
URL: https://github.com/apache/trafficserver/issues/13555

   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)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to