子网划分属于网络层地址规划，与NUMA延迟无关；解决NUMA延迟需让网络处理路径与内存物理位置对齐，包括确认网卡所属NUMA节点、绑定中断与软中断至同一节点、应用进程及内存分配均绑定至本地节点，并通过numastat等工具验证生效。

子网划分本身不处理 NUMA 延迟——它属于网络层地址规划，和 CPU 内存拓扑无关。真正要解决多核 CPU 在 NUMA 架构下的内存访问延迟，关键在“让网络处理路径与内存物理位置对齐”，而不是改子网掩码或 IP 段。

先确认网卡归属哪个 NUMA 节点

延迟根源往往始于硬件错位：网卡插在 Node 0 的 PCIe 插槽，但收包线程却在 Node 1 上跑。必须先查清物理绑定关系：

• 执行 cat /sys/class/net/eth0/device/numa_node（替换 eth0 为实际网卡名），输出 0 或 1 表示所属节点
• 配合 numactl --hardware 查看各节点 CPU 分布，比如 node 0 cpus: 0-7，node 1 cpus: 8-15
• 若输出为 -1，说明网卡未启用 NUMA 支持，需检查 BIOS 中是否开启 SR-IOV 或 ACS，或确认内核是否加载了对应驱动

把网络中断、软中断、应用线程绑到同一节点

三者错位一环，跨节点访存就无法避免：

• 硬中断：用 echo 0-7 > /proc/irq//smp_affinity_list 将网卡中断固定到 node 0 的 CPU 核心上，并 systemctl stop irqbalance
• 软中断：启用 RPS（Receive Packet Steering），例如 echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus（f 是十六进制，对应 CPU 0–3）
• 应用进程：启动时用 numactl --cpunodebind=0 --membind=0 ./your_app，确保线程运行和内存分配都在 node 0

代码层控制内存分配亲和性

仅靠启动参数不够，C++ 等程序需主动干预内存分配时机：

• 重载全局 operator new，内部调用 numa_alloc_onnode(size, numa_node_of_cpu(sched_getcpu()))
• 或特化 std::allocator，使 std::vector、std::string 等容器也走本地节点分配
• 注意：reserve() 不触发分配，真正分配发生在 push_back() 或 resize() 时，此时才走 allocator
• 避免常见坑：线程创建后才设置亲和性——构造函数中 global object 的 new 已在默认节点完成分配

验证是否真正生效

不验证等于没做：

• 查内存分布：numastat -p $PID，看 Heap 和 Stack 是否集中在目标节点（如 node 0 占比 >95%）
• 算跨节点比例：numastat -c $PID，关注 numa_foreign / (numa_hit + numa_foreign)，超过 5% 就需排查
• 核对 CPU 绑定：taskset -p $PID 输出的 hex mask 应与 numactl --hardware 中 node 0 的 CPU 列表一致