Hi, NVMe/TCP provides storage connectivity over standard Ethernet, but its CPU cost can limit throughput, particularly on DPUs. The goal is to improve throughput per core by embedding SPDK inside VPP and progressively removing unnecessary copies.
Over the past several weeks, Florin and I have been iterating on HostStack RX zero-copy, focusing on generic FIFO/session APIs, buffer ownership, deferred release and memory pressure. I propose upstreaming this incrementally: 1. An optional SPDK plugin using existing session APIs and copied RX/TX. 2. RX zero-copy combining Florin’s FIFO-backed API with SPDK’s receive-buffer work. 3. Separate TX optimizations, ultimately targeting the remaining FIFO-to-packet-buffer copy. This design still needs discussion. The initial plugin polls SPDK threads on VPP workers, builds SPDK without DPDK, and is independent of VPP’s NIC driver. It uses an unmodified upstream SPDK snapshot and requires no TCP, FIFO or driver changes. The updated reviews are: - https://gerrit.fd.io/r/c/vpp/+/46291 — optional build dependency - https://gerrit.fd.io/r/c/vpp/+/46292 — in-process target plugin Functional tests passed on ARM and x86, covering payload integrity and repeated startup, connection, disconnection and shutdown. The initial scope is Linux with software bdevs, without PCI-backed NVMe or TLS. Earlier architecture and BlueField-3 results: https://medium.com/fd-io-vpp/spdk-inside-vpp-accelerating-nvme-tcp-on-bluefield-3-bc0419048b1e I am willing to maintain the plugin and would appreciate feedback on this roadmap and the review and CI requirements. Best regards, Jerome
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27284): https://lists.fd.io/g/vpp-dev/message/27284 Mute This Topic: https://lists.fd.io/mt/121797177/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
