Zero-copy
How it works
Zero-copy is achieved through several complementary mechanisms: (1) mmap() maps a file or memory region directly into the process address space, so no separate copy is needed; (2) sendfile()/splice() move data between file descriptors entirely inside the kernel, bypassing the user-space buffer; (3) shared memory lets multiple processes read the same region without copying — only a pointer or handle is exchanged; (4) DMA (Direct Memory Access) lets a hardware controller move data between a device and memory without the CPU; (5) unified CPU–GPU memory and pointer passing eliminate host↔device copies. In every variant, instead of physically copying bytes a reference to the data is passed (pointer, offset, handle), and correctness is ensured by buffer ownership management and access synchronization.
Problem solved
Traditional data transfer copies the same bytes multiple times between buffers (kernel↔user space, process↔process, CPU↔GPU), burning CPU cycles and memory bandwidth and forcing context switches. For large data volumes (camera frames, network streams, tensors) these redundant copies become a performance bottleneck and a source of latency.
Components
Maps a file or memory region directly into the process address space, eliminating a copy into a separate user buffer.
Official
System calls that move data between descriptors (e.g. file→socket) entirely inside the kernel, bypassing the user-space buffer.
Official
A memory region accessible to multiple processes; instead of copying, a pointer/handle is exchanged. The basis of zero-copy in IPC middleware (e.g. iceoryx).
Official
Hardware-driven data transfer between a device (NIC, disk, GPU) and memory without CPU involvement; includes variants such as RDMA and GPUDirect.
Official
A shared CPU–GPU address space allowing data to be passed by pointer instead of a host↔device copy; key for GPU pipelines (e.g. Isaac ROS).
Official
Implementation
Releasing or overwriting a shared buffer before the consumer finishes reading leads to use-after-free bugs and data corruption.
Lack of synchronization on a shared region can yield inconsistent or partially written data.
mmap and DMA require page-boundary alignment; failing this breaks the mapping or forces a copy.
Data in shared memory is visible to other processes with access to it, increasing the attack surface.
When the transport layer does not support zero-copy, the system may silently fall back to copying, negating the expected performance gains.
Evolution
The sendfile() call first appeared in Linux 2.2, enabling file→socket transfer without copying data into user space.
splice() generalized zero-copy to arbitrary descriptor pairs, moving data through an in-kernel pipe.
Added zero-copy for sending network data directly from user-space buffers.
ROS 2 (Eloquent) introduced the loaned-messages API, enabling zero-copy via shared memory in DDS (e.g. Eclipse iceoryx, RTI Connext DDS Micro).
Type adaptation (REP-2007) and type negotiation (REP-2009) enabled zero-copy transport of GPU data between ROS 2 nodes.
Isaac ROS moved GPU zero-copy to native ROS 2 messages with rosidl::Buffer fields and a CUDA buffer backend.
Hyperparameters (configurable axes)
Who owns the shared buffer and when it can be safely released (loan/return model).
How reader–writer races in shared memory are prevented (mutex, barriers, versioning).
Required page-boundary alignment for mmap and DMA.
Behavior when the transport layer does not support zero-copy (e.g. ROS_DISABLE_LOANED_MESSAGES → fallback to a copy).
Computational complexity
Time complexity: O(1) kopii CPU (vs. O(n)). Space complexity: O(1) dodatkowej pamięci buforowej.
Hardware requirements
Zero-copy is a systems/software technique that works on any platform with an MMU and operating-system support.
Unified CPU–GPU memory and GPUDirect allow moving tensors between host and GPU without a copy, accelerating inference and vision pipelines.