Use of hsflowd on systems pushing 25G or more can increase system load to a level where packets are dropped. Security-oriented implementations often require high-granularity flow accounting which can preclude use of VyOS on such systems (without external modification).

Semper Victus builds its own kernels for VyOS which include the ipt_netflow code in-tree (for LTO/kCFI/RAP/KERNEXEC/etc purposes) and has used this facility effectively atop 100G bonds on a single Gold 5315Y. We have a back-ground task thread of our own to look into a similar mechanism for sFlow, but for the mean time, NetFlow collection from ring0 is probably the best option we have to handle these high-volume systems.

Propose that the VyOS team implement two changes to mitigate the resource exhaustion concern w/ hsflowd and provide an alternative flow collection for this class of router:

1. Alter the hsflowd service definition to include a CGroup CPU limit to prevent resource over-consumption (make it configurable by the user with a safe default)
2. Import the ipt_netflow code into the VyOS kernel along with the userspace tooling (we install iptables to handle this, but modification for nftables should not be hard) and expose it in the configuration separate from the sFlow collection tree since the data produced is a bit less granular.

I have not yet gotten my hands on any of the DP-Offload stuff (VPP/DPDK/whatever's afoot), but those mechanisms can provide facilities to do this sort of work without the expense of context-switching as well. OVS offload is another option which can facilitate semi-automatic HW offload to OFED, Intel NICs, and other "smart hardware."