[dave_taht]

The principal use case for any AQM is when stepping down from one speed to another, in the case of wireless, wildly variable rates, or in the case of 10Gbit to 1Gbit on a port (rfc7567), or shaping to customer rates via middlebox, like libreQos does (using XDP, currently).

In the non-shaping case, say going two 10Gbit ports into one...

what I had expected (in the future I saw in 2015) was that the FQ/AQM would be offloaded to hardware, and that vpp/ddpk would also get a timestamp and 5 tuple hash from the receive path's HW.

[gonzo]

The 5 tuple hash is easy. The timestamp is a clock read, which can be expensive.

[dave_taht]

At least some hardware provides the timestamp for you. Ideally if that's carried along with the packet, it measures the load on the whole system, so when you start dropping packets it's not just a function of network congestion but running out of cpu.

This would be a plus for a userspace router implementation, as presently in linux we timestamp on entry to the exit queue, not on all the overheads of routing lookup, and other processing from the read from the rx ring.