el.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=master</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-06-17T07:06:55Z</updated>
<entry>
<title>sfc: use budget for TX completions</title>
<updated>2023-06-17T07:06:55Z</updated>
<author>
<name>Íñigo Huguet</name>
<email>ihuguet@redhat.com</email>
</author>
<published>2023-06-15T08:49:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4aaf2c52834b7f95acdf9fb0211a1b60adbf421b'/>
<id>urn:sha1:4aaf2c52834b7f95acdf9fb0211a1b60adbf421b</id>
<content type='text'>
When running workloads heavy unbalanced towards TX (high TX, low RX
traffic), sfc driver can retain the CPU during too long times. Although
in many cases this is not enough to be visible, it can affect
performance and system responsiveness.

A way to reproduce it is to use a debug kernel and run some parallel
netperf TX tests. In some systems, this will lead to this message being
logged:
  kernel:watchdog: BUG: soft lockup - CPU#12 stuck for 22s!

The reason is that sfc driver doesn't account any NAPI budget for the TX
completion events work. With high-TX/low-RX traffic, this makes that the
CPU is held for long time for NAPI poll.

Documentations says "drivers can process completions for any number of Tx
packets but should only process up to budget number of Rx packets".
However, many drivers do limit the amount of TX completions that they
process in a single NAPI poll.

In the same way, this patch adds a limit for the TX work in sfc. With
the patch applied, the watchdog warning never appears.

Tested with netperf in different combinations: single process / parallel
processes, TCP / UDP and different sizes of UDP messages. Repeated the
tests before and after the patch, without any noticeable difference in
network or CPU performance.

Test hardware:
Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz (4 cores, 2 threads/core)
Solarflare Communications XtremeScale X2522-25G Network Adapter

Fixes: 5227ecccea2d ("sfc: remove tx and MCDI handling from NAPI budget consideration")
Fixes: d19a53721863 ("sfc_ef100: TX path for EF100 NICs")
Reported-by: Fei Liu &lt;feliu@redhat.com&gt;
Signed-off-by: Íñigo Huguet &lt;ihuguet@redhat.com&gt;
Acked-by: Martin Habets &lt;habetsm.xilinx@gmail.com&gt;
Link: https://lore.kernel.org/r/20230615084929.10506-1-ihuguet@redhat.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>sfc: support passing a representor to the EF100 TX path</title>
<updated>2022-07-22T11:50:06Z</updated>
<author>
<name>Edward Cree</name>
<email>ecree.xilinx@gmail.com</email>
</author>
<published>2022-07-20T18:33:47Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=02443ab8c9314134c9cd58946121726e4cd9a5c1'/>
<id>urn:sha1:02443ab8c9314134c9cd58946121726e4cd9a5c1</id>
<content type='text'>
A non-null efv in __ef100_enqueue_skb() indicates that the packet is
 from that representor, should be transmitted with a suitable option
 descriptor (to instruct the switch to deliver it to the representee),
 and should not be accounted to the parent PF's stats or BQL.

Signed-off-by: Edward Cree &lt;ecree.xilinx@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>