summaryrefslogtreecommitdiffstats
path: root/Documentation/networking/nfc.rst
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2024-04-29 10:47:05 +0100
committerDavid S. Miller <davem@davemloft.net>2024-04-29 10:47:05 +0100
commitfac87d32a092e0a987e3fb7a7821e2468e96f91c (patch)
treec0d86970d8ee07ef2745d7b0417423971eb7b55f /Documentation/networking/nfc.rst
parentb5327b9a300e2ecec1372ed375615f39e3df0542 (diff)
parent3b0b3019dbea1a110ff01896e00fe30804bf78bc (diff)
downloadlinux-stable-fac87d32a092e0a987e3fb7a7821e2468e96f91c.tar.gz
linux-stable-fac87d32a092e0a987e3fb7a7821e2468e96f91c.tar.bz2
linux-stable-fac87d32a092e0a987e3fb7a7821e2468e96f91c.zip
Merge branch 'mlxsw-events-processing-performance'
Petr Machata says: ==================== mlxsw: Improve events processing performance Amit Cohen writes: Spectrum ASICs only support a single interrupt, it means that all the events are handled by one IRQ (interrupt request) handler. Currently, we schedule a tasklet to handle events in EQ, then we also use tasklet for CQ, SDQ and RDQ. Tasklet runs in softIRQ (software IRQ) context, and will be run on the same CPU which scheduled it. It means that today we have one CPU which handles all the packets (both network packets and EMADs) from hardware. The existing implementation is not efficient and can be improved. Measuring latency of EMADs in the driver (without the time in FW) shows that latency is increased by factor of 28 (x28) when network traffic is handled by the driver. Measuring throughput in CPU shows that CPU can handle ~35% less packets of specific flow when corrupted packets are also handled by the driver. There are cases that these values even worse, we measure decrease of ~44% packet rate. This can be improved if network packet and EMADs will be handled in parallel by several CPUs, and more than that, if different types of traffic will be handled in parallel. We can achieve this using NAPI. This set converts the driver to process completions from hardware via NAPI. The idea is to add NAPI instance per CQ (which is mapped 1:1 to SDQ/RDQ), which means that each DQ can be handled separately. we have DQ for EMADs and DQs for each trap group (like LLDP, BGP, L3 drops, etc..). See more details in commit messages. An additional improvement which is done as part of this set is related to doorbells' ring. The idea is to handle small chunks of Rx packets (which is also recommended using NAPI) and ring doorbells once per chunk. This reduces the access to hardware which is expensive (time wise) and might take time because of memory barriers. With this set we can see better performance. To summerize: EMADs latency: +------------------------------------------------------------------------+ | | Before this set | Now | |------------------|---------------------------|-------------------------| | Increased factor | x28 | x1.5 | +------------------------------------------------------------------------+ Note that we can see even measurements that show better latency when traffic is handled by the driver. Throughput: +------------------------------------------------------------------------+ | | Before this set | Now | |-------------|----------------------------|-----------------------------| | Reduced | 35% | 6% | | packet rate | | | +------------------------------------------------------------------------+ Additional improvements are planned - use page pool for buffer allocations and avoid cache miss of each SKB using napi_build_skb(). Patch set overview: Patches #1-#2 improve access to hardware by reducing dorbells' rings Patch #3-#4 are preaparations for NAPI usage Patch #5 converts the driver to use NAPI ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking/nfc.rst')
0 files changed, 0 insertions, 0 deletions