Jakub Kicinski <[email protected]> writes:
> Extend ynltool to compute HW GRO savings metric - how many > packets has HW GRO been able to save the kernel from seeing. > > Note that this definition does not actually take into account > whether the segments were or weren't eligible for HW GRO. > If a machine is receiving all-UDP traffic - new metric will show > HW-GRO savings of 0%. Conversely since the super-packet still > counts as a received packet, savings of 100% is not achievable. > Perfect HW-GRO on a machine with 4k MTU and 64kB super-frames > would show ~93.75% savings. With 1.5k MTU we may see up to > ~97.8% savings (if my math is right). > > Example after 10 sec of iperf on a freshly booted machine > with 1.5k MTU: > > $ ynltool qstats show > eth0 rx-packets: 40681280 rx-bytes: 61575208437 > rx-alloc-fail: 0 rx-hw-gro-packets: 1225133 > rx-hw-gro-wire-packets: 40656633 > $ ynltool qstats hw-gro > eth0: 96.9% savings > > None of the NICs I have access to can report "missed" HW-GRO > opportunities so computing a true "effectiveness" metric > is not possible. One could also argue that effectiveness metric > is inferior in environments where we control both senders and > receivers, the savings metrics will capture both regressions > in receiver's HW GRO effectiveness but also regressions in senders > sending smaller TSO trains. And we care about both. The main > downside is that it's hard to tell at a glance how well the NIC > is doing because the savings will be dependent on traffic patterns. > > Signed-off-by: Jakub Kicinski <[email protected]> Reviewed-by: Petr Machata <[email protected]>
