Jun 6, 2026

The current bridge methods already accept an arbitrary row count and internally split the work into hardware-sized chunks. So from the caller side the format remains unchanged: rows = [record | optional correlation key] * n For example: ufsecp_lbtc_verify_ecdsa(ctrl, rows, row_count, key_size, results); or for collect mode: ufsecp_lbtc_verify_ecdsa_collect(ctrl, rows, row_count, key_size); You do not need to pre-split the batch unless you want to for your own mmap / scheduling reasons. The bridge walks the input in internal chunks and dispatches each chunk to GPU or CPU fallback. So sending a very large row count is logically fine, including “a billion rows”, assuming: - the row buffer is addressable and remains valid for the duration of the call; - `results` has `row_count` bytes for the results API; - `row_count * stride` fits the platform address space / `size_t`; - the mmap/page-cache behavior is acceptable for that one long call. The bridge should not fail merely because the count is larger than the device batch size. Device-sized batching is handled inside the bridge. The main practical limits are memory mapping, addressability, result-buffer size, and how much latency you want in a single call before control returns to the caller.