[LibreQoS] Fwd: [PATCH net-next 0/4] tsnep: Throttle irq, rotten pkts, RX buffer alloc and ethtool_get_channels()

[LibreQoS] Fwd: [PATCH net-next 0/4] tsnep: Throttle irq, rotten pkts, RX buffer alloc and ethtool_get_channels()

[Dave Taht]

time sensitive networking is a thing. Now less sensitive. At least on
this a53, an interrupt rate of 20us resulted in total cpu usage at a
gbit...

Taking a 7x hit in latency tho, to reduce the cpu load, strikes me as
a lot. dpdk would just spin-read here, vs a vs xdp.

"Without interrupt throttling, iperf server mode generates a CPU load of
100% (A53 1.2GHz). Also the throughput suffers with less than 900Mbit/s
on a 1Gbit/s link. The reason is a high interrupt load with interrupts
every ~20us.

Reduce interrupt load by throttling of interrupts. Interrupt delay is
configured statically to 64us. For iperf server mode the CPU load is
significantly reduced to ~20% and the throughput reaches the maximum of
941MBit/s. Interrupts are generated every ~140us."


---------- Forwarded message ---------
From: Gerhard Engleder <gerhard@engleder-embedded.com>
Date: Thu, Nov 17, 2022 at 12:40 PM
Subject: [PATCH net-next 0/4] tsnep: Throttle irq, rotten pkts, RX
buffer alloc and ethtool_get_channels()
To: <netdev@vger.kernel.org>
Cc: <davem@davemloft.net>, <kuba@kernel.org>, <edumazet@google.com>,
<pabeni@redhat.com>, Gerhard Engleder <gerhard@engleder-embedded.com>


Collection of improvements found during development of XDP support.
Hopefully the last patch series before the XDP support.

Fix of rotten packets increased CPU load and caused slight drop of iperf
performance, because CPU load was already at 100% before. This performance
drop is compensated with interrupt throttling, which makes sense anyway.

ethtool_get_channels() is needed for automatic TAPRIO configuration in
combination with multiple queues.

Rework of RX buffer allocation is prework of XDP. It ensures that packets
are only dropped if RX queue would otherwise run empty because of
failed allocations. So it should reduce the number of dropped packets
under low memory conditions.

Gerhard Engleder (4):
  tsnep: Throttle interrupts
  tsnep: Fix rotten packets
  tsnep: Add ethtool get_channels support
  tsnep: Rework RX buffer allocation

 drivers/net/ethernet/engleder/tsnep.h         |   4 +
 drivers/net/ethernet/engleder/tsnep_ethtool.c |  19 ++
 drivers/net/ethernet/engleder/tsnep_hw.h      |   7 +
 drivers/net/ethernet/engleder/tsnep_main.c    | 252 +++++++++++++-----
 4 files changed, 214 insertions(+), 68 deletions(-)

--
2.30.2



--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC

Re: [LibreQoS] Fwd: [PATCH net-next 0/4] tsnep: Throttle irq, rotten pkts, RX buffer alloc and ethtool_get_channels()

[Gerhard Engleder]

On 17.11.22 22:02, Dave Taht wrote:
> time sensitive networking is a thing. Now less sensitive. At least on
> this a53, an interrupt rate of 20us resulted in total cpu usage at a
> gbit...
> 
> Taking a 7x hit in latency tho, to reduce the cpu load, strikes me as
> a lot. dpdk would just spin-read here, vs a vs xdp.

7x less interrupts does not mean that latency is also 7x higher, but
latency will definitely be increased. A balance between CPU load and
latency need to be found here.

> "Without interrupt throttling, iperf server mode generates a CPU load of
> 100% (A53 1.2GHz). Also the throughput suffers with less than 900Mbit/s
> on a 1Gbit/s link. The reason is a high interrupt load with interrupts
> every ~20us.
> 
> Reduce interrupt load by throttling of interrupts. Interrupt delay is
> configured statically to 64us. For iperf server mode the CPU load is
> significantly reduced to ~20% and the throughput reaches the maximum of
> 941MBit/s. Interrupts are generated every ~140us."