MACsec-Protected RDMA on DPUs: From Linux Netdev State to Workload Scheduling#

Alkama Hasan and Vijay Ram Inavolu

Why: It sits exactly on the intersection this PM cares about — physical fabric encryption, DPU offload, and Kubernetes scheduling — and it names a real gap: RDMA verbs bypass the kernel, so kTLS and in-kernel IPsec cannot protect the path that KV-cache, gradients and model weights actually cross.

What: Carry DPU-side MACsec datapath state up into the host-visible RDMA netdev, then let a Kubernetes DRA network driver (DRANet) publish "MACsec-capable" as a schedulable property alongside RDMA, SR-IOV and NUMA locality in the node's ResourceSlice.

How: MACsec (802.1AE) sits at L2, below the RDMA transport, so a hardware-offloaded MACsec engine encrypts egress under RoCE with no host CPU crypto cost; the kernel already has the plumbing (macsec_ops, NETIF_F_HW_MACSEC, ip macsec offload mac). The hard part is the split: the host sees an RDMA-capable PCIe function while the MACsec engine, egress port and control plane live on the DPU. DRANet-Sec turns the resulting netdev feature advertisement into a ResourceSlice entry, so a pod requests placement on nodes where RDMA egress is genuinely protected — MACsec becomes a second offload stacked under RDMA, invisible to the workload. The talk's stated focus is keeping the advertised capability aligned with the real protected datapath, a problem that recurs for any DPU-resident offload exposed to the scheduler.

Where applicable: Multi-tenant AI/HPC clusters with DPU-based RDMA; demonstrated on a DPU testbed with the Red Hat DPU Operator / OpenShift + Cilium offload stack as context. The capability-advertisement-vs-reality problem generalizes to every DRA-scheduled hardware feature.