This document describes the current limitations and constraints of the dpdk-net crate.
smoltcp implements simple congestion control, not advanced algorithms like CUBIC or BBR. This affects throughput on high-latency or lossy networks. For data center use cases with low-latency, reliable networks, this is less of an issue.
smoltcp does not support advanced TCP features:
- No TCP Fast Open (TFO)
- No Selective Acknowledgment (SACK)
- No Explicit Congestion Notification (ECN)
- No TCP window scaling beyond basic support
smoltcp uses fixed-size socket buffers configured at socket creation time. This limits the number of concurrent connections that can be efficiently handled, as memory is pre-allocated rather than dynamically sized.
Each hardware queue is processed by a single thread. There is no work-stealing between queues, so uneven load distribution can occur if RSS hashing produces an imperfect distribution of connections.
Only queue 0 receives and processes ARP replies (since ARP is not matched by TCP RSS rules). Other queues depend on the SharedArpCache injection mechanism, which may have slight staleness before entries propagate.
Packets that arrive on the wrong queue (due to RSS hash collisions or asymmetric routing) cannot be migrated to the correct queue. The packet is processed by the receiving queue's smoltcp instance, which may not have the connection state.
DPDK is poll-based, not interrupt-driven. CPU cores running the reactor are always at 100% utilization even when idle. There is no power-saving mode or interrupt coalescing.
The library is primarily designed for TCP workloads. UDP support is only partially implemented.
While smoltcp supports IPv6, the multi-queue RSS configuration has not been tested with IPv6 traffic.
The library provides raw TCP streams. TLS must be integrated separately using crates like rustls or tokio-rustls.
IP addresses must be configured statically. There is no DHCP client support.
DPDK requires:
- Root privileges (or specific capabilities)
- Hugepage memory allocation
- Access to
/dev/hugepagesor equivalent
This prevents use in unprivileged containers without host configuration.
Production deployments require a DPDK-compatible NIC with a supported PMD (Poll Mode Driver). Virtual devices (net_ring0, net_null0) are only suitable for testing.
The following hardware offloads are not implemented:
- TCP Segmentation Offload (TSO)
- Large Receive Offload (LRO)
- TCP/UDP checksum offload
- Receive Side Coalescing (RSC)
All packet processing is done in software by smoltcp.
Each queue requires its own smoltcp interface with dedicated socket buffers. With many queues and connections, memory usage can grow significantly.
Closing connections during shutdown may not complete TCP's FIN handshake if the reactor stops polling before the connection fully closes.
The bridge relays data through tokio::sync::mpsc channels, adding one memcpy per direction. This adds ~1-5µs latency per hop. For maximum throughput, run code directly on lcores via DpdkApp::run.
Data is copied between Bytes buffers and DPDK mbufs. True zero-copy would require exposing mbuf lifetimes across threads, conflicting with DPDK's per-thread mempool caching.
The bridge worker uses a simple sequential allocator (49152–65535) without reuse tracking. Under heavy churn, port exhaustion is possible.