ChaosAttractor

了解了以下，支持 switchdev 的话确实 vf 或者多个 pf （包括拆分后的）可以直接通过 linux bridge 片上交换
这么看 e810 确实是可行的，但是还是推荐 mellanox
楼主节点多的话建议整个交换机吧，少折磨自己（

说实话不太有，而且多 function/virtual function 片上交换是的 bridge 就可以实现 offload 的吗？
得用 openvswitch 和 openflow + switchdev 吧，你先确定能用上再说

v6 可以保证所有设备都具有公网 IP ，这对于实现零信任+零配置的完全点对点通信意义重大

如果要给 linux 平台开发 electron 软件，请务必考虑一下在 wayland 下的输入法问题，即便现在 xorg 还能用，但 wayland 也是趋势
而 wayland 下 electron 仅支持 text-input-v1 ，目前大部分 compositor 没有且不打算支持（但未来可能会更好，比如说 mutter 现在已经有了相关 pr ）
现状可以参考： https://www.csslayer.info/wordpress/fcitx-dev/chrome-state-of-input-method-on-wayland/
而 Tarui 则完全没有 chromium 所带来的问题

家庭网络中的数据平面一般是完全扁平的，为什么需要 SDN?
如果你需要，这已经和一般认知中的家庭网络差了十万八千里了

如果连一个不开 PMF 的开启 802.11k/v/r 的 WPA2-PSK 的 2.4/5Ghz 混合 SSID 都连不了 IoT 设备，那我觉得真的可以退了，折磨自己，虽然你的确可以单独开一个 SSID ，但考虑到 IoT 设备一般会有二层互联的需求，这等同于降低整个网络的安全性

@ChaosAttractor 修正 此外 FRP 等一般用于单一的静态 **端口** 的穿透（转发），而作为 Default Route 则需要能被三层路由原始流量的能力

这些都是 Linux 的容器化技术，内核层面依赖 CGourps 实现，它可以提供在同一个内核中隔离多个用户空间进程，你可以理解为 LXC 里面的进程和外面的进程性能什么都是一样的（当然也可以限制），只是所有东西互相隔离
共享内核意味着 0 额外性能和内存开销，只有里面的进程会占用内存
而 LXC 则是管理管理 CGroups 和各种 Namespace 隔离的用户空间程序，类似的还有 ContainerD 和 LXD ，Docker 和 K8S 则基于 ContainerD
此外它们支持嵌套，所以在 LXC 中运行 Docker 并无不妥，因为 LXC 一般直接用于替代 Hypervisor
但 LXC 的网络基于内核的 NetNS ，并且因为共享内核和非特权的设计使得 eBPF 和 iptables/nftables 功能受限，而且大概率你还需要 CPU 转发（虚拟化则你可以直通网卡），各种硬件卸载功能也受限（当然如果你在用最新最热的 Mellanox 网卡那支持的还蛮好的）
一般作为路由我觉得不太合适