Bringing NoLoad® Cryptographic Acceleration to FreeBSD

FreeBSD quietly underpins some of the most demanding infrastructure on the planet: large-scale content delivery and streaming, storage and security appliances, the network edge. It’s the OS of choice when you need a tight, predictable kernel, and world-class networking.

Through collaboration with a partner, we have worked to bring NoLoad® acceleration to FreeBSD without compromising performance. This has been accomplished through a new purpose-built driver designed to deploy without modifying the base kernel. It installs alongside FreeBSD’s existing NVMe stack, requires no kernel changes, and delivers Linux-class performance from the onset. That combination of drop-in deployment with full acceleration is the focus of what follows: why it mattered, what we built, and the results.

‍

FreeBSD and Hardware Offload

Not every serious workload runs on Linux. FreeBSD’s role in CDN, storage, networking, and security is well known to the operators who run it, and those workloads are exactly the kind that benefit most from hardware-accelerated cryptography, compression, and erasure coding. Customers building on FreeBSD should not have to give up modern acceleration to do it. NoLoad is a platform play, not a Linux-only play.

‍

NVMe Path Shortcomings

NoLoad presents to the host as a standard NVMe device, and FreeBSD has a capable NVMe stack, so in principle it works out of the box. But accelerator workloads are not storage workloads. Cryptographic offload, compression, and erasure coding have very different queueing, submission, and completion characteristics from reading and writing blocks: more in-flight commands, deeper parallelism, different payload profiles, and no tolerance for the latency overheads that are immaterial to typical disk I/O. The generic NVMe path treats an accelerator as a disk, leaving significant performance unrealized. It is the same reason many of our Linux customers run our purpose-built driver rather than the stock one.

‍

Driver Architecture

The new FreeBSD driver for NoLoad is designed around accelerator queue semantics rather than storage semantics. At its core is a new “algo” command: input and output data travel in a single command with separate PRP lists, so one submission and one completion fully describe an acceleration operation. This is the distinction between treating the device as an accelerator and treating it as a disk. The offload path is purpose-built, but NoLoad remains a standard NVMe device for administration, so the usual management functions, including firmware updates and device health monitoring, continue to work through the normal NVMe admin path.

Equally important is how it deploys. The driver installs alongside FreeBSD’s existing NVMe driver and requires no changes to the base kernel, which for most operators removes the principal barrier to adoption. The standalone driver is a copy of the upstream FreeBSD NVMe driver with a patch applied, renamed to nvme_noload and restricted to bind only Eideticom devices, so it operates next to the stock driver without affecting it. Architects who prefer full visibility into the changes can instead patch the stock driver directly; either path is supported.

The outcome: storage and accelerator workloads run side by side on the same machine, with no compromise on either.

‍

Regression Testing

FreeBSD is a full production platform in our CI pipeline. We test against FreeBSD 13, 14, 15, and 16-CURRENT, with automated regression coverage on every internal commit and pull request. On the software side, the test suite builds the NoLoad userspace library across multiple configurations and validates correct behaviour without a device present. Because FreeBSD ships OpenSSL 3.5 in the base system, our OpenSSL provider for the cryptography accelerator integrates against the system directly. Every software run also builds and installs the FreeBSD pkg packages and tarballs, verifies that the installed artifacts function correctly, and confirms that the full install and uninstall lifecycle works end to end.

On the hardware side, the suite runs against a physical NoLoad FPGA device across a variety of setups on every internal commit. At the accelerator level, core hardware unit tests exercise the NoLoad queue and command interface directly, the same submit and complete path the driver exposes. Compression offload is tested separately through dedicated hardware unit tests, which validate that data moving through the FPGA produces correct output under a range of conditions, including error injection. The NoLoad OpenSSL provider is tested end to end against a live nginx instance, terminating TLS connections across multiple cipher curves with hardware offload active. If a change breaks the accelerator interface, regresses compression, or disrupts TLS offload, it is caught before it ships. Full CI pipeline integration establishes FreeBSD as a fully supported, production-ready platform for NoLoad.

‍

Implications for FreeBSD Deployments

NoLoad enables teams running cryptography-heavy workloads on FreeBSD. Whether it’s TLS termination at scale, encrypted storage, secure networking, or content protection, the power and TCO case for offloading to NoLoad is now the same as it has been on Linux.

More broadly, this reflects how we think about acceleration: a platform that only runs well on one OS isn’t really a platform. Our FreeBSD work is part of a continued investment in making accelerated infrastructure available wherever our customers choose to build.