Linux-kselftest-mirror November 2024

linux-kselftest-mirror@lists.linaro.org

5 participants
5 discussions

[PATCH net-next v11 00/23] Introducing OpenVPN Data Channel Offload

by Antonio Quartulli

Notable changes from v10: * extended commit message of 23/23 with brief description of the output * Link to v10: https://lore.kernel.org/r/20241025-b4-ovpn-v10-0-b87530777be7@openvpn.net Please note that some patches were already reviewed by Andre Lunn, Donald Hunter and Shuah Khan. They have retained the Reviewed-by tag since no major code modification has happened since the review. The latest code can also be found at: https://github.com/OpenVPN/linux-kernel-ovpn Thanks a lot! Best Regards, Antonio Quartulli OpenVPN Inc. --- Antonio Quartulli (23): netlink: add NLA_POLICY_MAX_LEN macro net: introduce OpenVPN Data Channel Offload (ovpn) ovpn: add basic netlink support ovpn: add basic interface creation/destruction/management routines ovpn: keep carrier always on ovpn: introduce the ovpn_peer object ovpn: introduce the ovpn_socket object ovpn: implement basic TX path (UDP) ovpn: implement basic RX path (UDP) ovpn: implement packet processing ovpn: store tunnel and transport statistics ovpn: implement TCP transport ovpn: implement multi-peer support ovpn: implement peer lookup logic ovpn: implement keepalive mechanism ovpn: add support for updating local UDP endpoint ovpn: add support for peer floating ovpn: implement peer add/get/dump/delete via netlink ovpn: implement key add/get/del/swap via netlink ovpn: kill key and notify userspace in case of IV exhaustion ovpn: notify userspace when a peer is deleted ovpn: add basic ethtool support testing/selftests: add test tool and scripts for ovpn module Documentation/netlink/specs/ovpn.yaml | 362 +++ MAINTAINERS | 11 + drivers/net/Kconfig | 14 + drivers/net/Makefile | 1 + drivers/net/ovpn/Makefile | 22 + drivers/net/ovpn/bind.c | 54 + drivers/net/ovpn/bind.h | 117 + drivers/net/ovpn/crypto.c | 214 ++ drivers/net/ovpn/crypto.h | 145 ++ drivers/net/ovpn/crypto_aead.c | 386 ++++ drivers/net/ovpn/crypto_aead.h | 33 + drivers/net/ovpn/io.c | 462 ++++ drivers/net/ovpn/io.h | 25 + drivers/net/ovpn/main.c | 337 +++ drivers/net/ovpn/main.h | 24 + drivers/net/ovpn/netlink-gen.c | 212 ++ drivers/net/ovpn/netlink-gen.h | 41 + drivers/net/ovpn/netlink.c | 1135 ++++++++++ drivers/net/ovpn/netlink.h | 18 + drivers/net/ovpn/ovpnstruct.h | 61 + drivers/net/ovpn/packet.h | 40 + drivers/net/ovpn/peer.c | 1201 ++++++++++ drivers/net/ovpn/peer.h | 165 ++ drivers/net/ovpn/pktid.c | 130 ++ drivers/net/ovpn/pktid.h | 87 + drivers/net/ovpn/proto.h | 104 + drivers/net/ovpn/skb.h | 56 + drivers/net/ovpn/socket.c | 178 ++ drivers/net/ovpn/socket.h | 55 + drivers/net/ovpn/stats.c | 21 + drivers/net/ovpn/stats.h | 47 + drivers/net/ovpn/tcp.c | 506 +++++ drivers/net/ovpn/tcp.h | 44 + drivers/net/ovpn/udp.c | 406 ++++ drivers/net/ovpn/udp.h | 26 + include/net/netlink.h | 1 + include/uapi/linux/if_link.h | 15 + include/uapi/linux/ovpn.h | 109 + include/uapi/linux/udp.h | 1 + tools/net/ynl/ynl-gen-c.py | 4 +- tools/testing/selftests/Makefile | 1 + tools/testing/selftests/net/ovpn/.gitignore | 2 + tools/testing/selftests/net/ovpn/Makefile | 17 + tools/testing/selftests/net/ovpn/config | 10 + tools/testing/selftests/net/ovpn/data64.key | 5 + tools/testing/selftests/net/ovpn/ovpn-cli.c | 2370 ++++++++++++++++++++ tools/testing/selftests/net/ovpn/tcp_peers.txt | 5 + .../testing/selftests/net/ovpn/test-chachapoly.sh | 9 + tools/testing/selftests/net/ovpn/test-float.sh | 9 + tools/testing/selftests/net/ovpn/test-tcp.sh | 9 + tools/testing/selftests/net/ovpn/test.sh | 183 ++ tools/testing/selftests/net/ovpn/udp_peers.txt | 5 + 52 files changed, 9494 insertions(+), 1 deletion(-) --- base-commit: ab101c553bc1f76a839163d1dc0d1e715ad6bb4e change-id: 20241002-b4-ovpn-eeee35c694a2 Best regards, -- Antonio Quartulli <antonio(a)openvpn.net>

7 minutes

[PATCH net-next v3 0/7] Suspend IRQs during application busy periods

by Joe Damato

Greetings: Welcome to v3, see changelog below. Note that our performance tests were not re-run for this revision as we only updated a commit message and added a selftest. This series introduces a new mechanism, IRQ suspension, which allows network applications using epoll to mask IRQs during periods of high traffic while also reducing tail latency (compared to existing mechanisms, see below) during periods of low traffic. In doing so, this balances CPU consumption with network processing efficiency. Martin Karsten (CC'd) and I have been collaborating on this series for several months and have appreciated the feedback from the community on our RFC [1]. We've updated the cover letter and kernel documentation in an attempt to more clearly explain how this mechanism works, how applications can use it, and how it compares to existing mechanisms in the kernel. We've added an additional test case, 'fullbusy', achieved by modifying libevent for comparison. See below for a detailed description, link to the patch, and test results. I briefly mentioned this idea at netdev conf 2024 (for those who were there) and Martin described this idea in an earlier paper presented at Sigmetrics 2024 [2]. ~ The short explanation (TL;DR) We propose adding a new napi config parameter: irq_suspend_timeout to help balance CPU usage and network processing efficiency when using IRQ deferral and napi busy poll. If this parameter is set to a non-zero value *and* a user application has enabled preferred busy poll on a busy poll context (via the EPIOCSPARAMS ioctl introduced in commit 18e2bf0edf4d ("eventpoll: Add epoll ioctl for epoll_params")), then application calls to epoll_wait for that context will cause device IRQs and softirq processing to be suspended as long as epoll_wait successfully retrieves data from the NAPI. Each time data is retrieved, the irq_suspend_timeout is deferred. If/when network traffic subsides and epoll_wait returns no data, IRQ suspension is immediately reverted back to the existing napi_defer_hard_irqs and gro_flush_timeout mechanism which was introduced in commit 6f8b12d661d0 ("net: napi: add hard irqs deferral feature")). The irq_suspend_timeout serves as a safety mechanism. If userland takes a long time processing data, irq_suspend_timeout will fire and restart normal NAPI processing. For a more in depth explanation, please continue reading. ~ Comparison with existing mechanisms Interrupt mitigation can be accomplished in napi software, by setting napi_defer_hard_irqs and gro_flush_timeout, or via interrupt coalescing in the NIC. This can be quite efficient, but in both cases, a fixed timeout (or packet count) needs to be configured. However, a fixed timeout cannot effectively support both low- and high-load situations: At low load, an application typically processes a few requests and then waits to receive more input data. In this scenario, a large timeout will cause unnecessary latency. At high load, an application typically processes many requests before being ready to receive more input data. In this case, a small timeout will likely fire prematurely and trigger irq/softirq processing, which interferes with the application's execution. This causes overhead, most likely due to cache contention. While NICs attempt to provide adaptive interrupt coalescing schemes, these cannot properly take into account application-level processing. An alternative packet delivery mechanism is busy-polling, which results in perfect alignment of application processing and network polling. It delivers optimal performance (throughput and latency), but results in 100% cpu utilization and is thus inefficient for below-capacity workloads. We propose to add a new packet delivery mode that properly alternates between busy polling and interrupt-based delivery depending on busy and idle periods of the application. During a busy period, the system operates in busy-polling mode, which avoids interference. During an idle period, the system falls back to interrupt deferral, but with a small timeout to avoid excessive latencies. This delivery mode can also be viewed as an extension of basic interrupt deferral, but alternating between a small and a very large timeout. This delivery mode is efficient, because it avoids softirq execution interfering with application processing during busy periods. It can be used with blocking epoll_wait to conserve cpu cycles during idle periods. The effect of alternating between busy and idle periods is that performance (throughput and latency) is very close to full busy polling, while cpu utilization is lower and very close to interrupt mitigation. ~ Usage details IRQ suspension is introduced via a per-NAPI configuration parameter that controls the maximum time that IRQs can be suspended. Here's how it is intended to work: - The user application (or system administrator) uses the netdev-genl netlink interface to set the pre-existing napi_defer_hard_irqs and gro_flush_timeout NAPI config parameters to enable IRQ deferral. - The user application (or system administrator) sets the proposed irq_suspend_timeout parameter via the netdev-genl netlink interface to a larger value than gro_flush_timeout to enable IRQ suspension. - The user application issues the existing epoll ioctl to set the prefer_busy_poll flag on the epoll context. - The user application then calls epoll_wait to busy poll for network events, as it normally would. - If epoll_wait returns events to userland, IRQs are suspended for the duration of irq_suspend_timeout. - If epoll_wait finds no events and the thread is about to go to sleep, IRQ handling using napi_defer_hard_irqs and gro_flush_timeout is resumed. As long as epoll_wait is retrieving events, IRQs (and softirq processing) for the NAPI being polled remain disabled. When network traffic reduces, eventually a busy poll loop in the kernel will retrieve no data. When this occurs, regular IRQ deferral using gro_flush_timeout for the polled NAPI is re-enabled. Unless IRQ suspension is continued by subsequent calls to epoll_wait, it automatically times out after the irq_suspend_timeout timer expires. Regular deferral is also immediately re-enabled when the epoll context is destroyed. ~ Usage scenario The target scenario for IRQ suspension as packet delivery mode is a system that runs a dominant application with substantial network I/O. The target application can be configured to receive input data up to a certain batch size (via epoll_wait maxevents parameter) and this batch size determines the worst-case latency that application requests might experience. Because packet delivery is suspended during the target application's processing, the batch size also determines the worst-case latency of concurrent applications using the same RX queue(s). gro_flush_timeout should be set as small as possible, but large enough to make sure that a single request is likely not being interfered with. irq_suspend_timeout is largely a safety mechanism against misbehaving applications. It should be set large enough to cover the processing of an entire application batch, i.e., the factor between gro_flush_timeout and irq_suspend_timeout should roughly correspond to the maximum batch size that the target application would process in one go. ~ Design rationale The implementation of the IRQ suspension mechanism very nicely dovetails with the existing mechanism for IRQ deferral when preferred busy poll is enabled (introduced in commit 7fd3253a7de6 ("net: Introduce preferred busy-polling"), see that commit message for more details). While it would be possible to inject the suspend timeout via the existing epoll ioctl, it is more natural to avoid this path for one main reason: An epoll context is linked to NAPI IDs as file descriptors are added; this means any epoll context might suddenly be associated with a different net_device if the application were to replace all existing fds with fds from a different device. In this case, the scope of the suspend timeout becomes unclear and many edge cases for both the user application and the kernel are introduced Only a single iteration through napi busy polling is needed for this mechanism to work effectively. Since an important objective for this mechanism is preserving cpu cycles, exactly one iteration of the napi busy loop is invoked when busy_poll_usecs is set to 0. ~ Important call outs in the implementation - Enabling per epoll-context preferred busy poll will now effectively lead to a nonblocking iteration through napi_busy_loop, even when busy_poll_usecs is 0. See patch 4. - Patches apply cleanly on commit 160a810b2a85 ("net: vxlan: update the document for vxlan_snoop()"). ~ Benchmark configs & descriptions The changes were benchmarked with memcached [3] using the benchmarking tool mutilate [4]. To facilitate benchmarking, a small patch [5] was applied to memcached 1.6.29 to allow setting per-epoll context preferred busy poll and other settings via environment variables. Another small patch [6] was applied to libevent to enable full busy-polling. Multiple scenarios were benchmarked as described below and the scripts used for producing these results can be found on github [7] (note: all scenarios use NAPI-based traffic splitting via SO_INCOMING_ID by passing -N to memcached): - base: - no other options enabled - deferX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - napibusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 200,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 64, busy_poll_budget = 64, prefer_busy_poll = true) - fullbusy: - set defer_hard_irqs to 100 - set gro_flush_timeout to 5,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 1000, busy_poll_budget = 64, prefer_busy_poll = true) - change memcached's nonblocking epoll_wait invocation (via libevent) to using a 1 ms timeout - suspendX: - set defer_hard_irqs to 100 - set gro_flush_timeout to X,000 - set irq_suspend_timeout to 20,000,000 - enable busy poll via the existing ioctl (busy_poll_usecs = 0, busy_poll_budget = 64, prefer_busy_poll = true) ~ Benchmark results Tested on: Single socket AMD EPYC 7662 64-Core Processor Hyperthreading disabled 4 NUMA Zones (NPS=4) 16 CPUs per NUMA zone (64 cores total) 2 x Dual port 100gbps Mellanox Technologies ConnectX-5 Ex EN NIC The test machine is configured such that a single interface has 8 RX queues. The queues' IRQs and memcached are pinned to CPUs that are NUMA-local to the interface which is under test. The NIC's interrupt coalescing configuration is left at boot-time defaults. Results: Results are shown below. The mechanism added by this series is represented by the 'suspend' cases. Data presented shows a summary over at least 10 runs of each test case [8] using the scripts on github [7]. For latency, the median is shown. For throughput and CPU utilization, the average is shown. The results also include cycles-per-query (cpq) and instruction-per-query (ipq) metrics, following the methodology proposed in [2], to augment the CPU utilization numbers, which could be skewed due to frequency scaling. We find that this does not appear to be the case as CPU utilization and low-level metrics show similar trends. These results were captured using the scripts on github [7] to illustrate how this approach compares with other pre-existing mechanisms. This data is not to be interpreted as scientific data captured in a fully isolated lab setting, but instead as best effort, illustrative information comparing and contrasting tradeoffs. The absolute QPS results are higher than our previous submission, but the relative differences between variants are equivalent. Because the patches have been rebased on 6.12, several factors have likely influenced the overall performance. Most importantly, we had to switch to a new set of basic kernel options, which has likely altered the baseline performance. Because the overall comparison of variants still holds, we have not attempted to recreate the exact set of kernel options from the previous submission. Compare: - Throughput (MAX) and latencies of base vs suspend. - CPU usage of napibusy and fullbusy during lower load (200K, 400K for example) vs suspend. - Latency of the defer variants vs suspend as timeout and load increases. The overall takeaway is that the suspend variants provide a superior combination of high throughput, low latency, and low cpu utilization compared to all other variants. Each of the suspend variants works very well, but some fine-tuning between latency and cpu utilization is still possible by tuning the small timeout (gro_flush_timeout). Note: we've reorganized the results to make comparison among testcases with the same load easier. testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 200K 200024 127 254 458 25 12748 11289 defer10 200K 199991 64 128 166 27 18763 16574 defer20 200K 199986 72 135 178 25 15405 14173 defer50 200K 200025 91 149 198 23 12275 12203 defer200 200K 199996 182 266 326 18 8595 9183 fullbusy 200K 200040 58 123 167 100 43641 23145 napibusy 200K 200009 115 244 299 56 24797 24693 suspend10 200K 200005 63 128 167 32 19559 17240 suspend20 200K 199952 69 132 170 29 16324 14838 suspend50 200K 200019 84 144 189 26 13106 12516 suspend200 200K 199978 168 264 326 20 9331 9643 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 400K 400017 157 292 762 39 9287 9325 defer10 400K 400033 71 141 204 53 13950 12943 defer20 400K 399935 79 150 212 47 12027 11673 defer50 400K 399888 101 171 231 39 9556 9921 defer200 400K 399993 200 287 358 32 7428 8576 fullbusy 400K 400018 63 132 203 100 21827 16062 napibusy 400K 399970 89 230 292 83 18156 16508 suspend10 400K 400061 69 139 202 54 13576 13057 suspend20 400K 399988 73 144 206 49 11930 11773 suspend50 400K 399975 88 161 218 42 9996 10270 suspend200 400K 399954 172 276 353 34 7847 8713 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 600K 600031 166 289 631 61 9188 8787 defer10 600K 599967 85 167 262 75 11833 10947 defer20 600K 599888 89 165 243 66 10513 10362 defer50 600K 600072 109 185 253 55 8664 9190 defer200 600K 599951 222 315 393 45 6892 8213 fullbusy 600K 600041 69 145 227 100 14549 13936 napibusy 600K 599980 79 188 280 96 13927 14155 suspend10 600K 600028 78 159 267 69 10877 11032 suspend20 600K 600026 81 159 254 64 9922 10320 suspend50 600K 600007 96 178 258 57 8681 9331 suspend200 600K 599964 177 295 369 47 7115 8366 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 800K 800034 198 329 698 84 9366 8338 defer10 800K 799718 243 642 1457 95 10532 9007 defer20 800K 800009 132 245 399 89 9956 8979 defer50 800K 800024 136 228 378 80 9002 8598 defer200 800K 799965 255 362 473 66 7481 8147 fullbusy 800K 799927 78 157 253 100 10915 12533 napibusy 800K 799870 81 173 273 99 10826 12532 suspend10 800K 799991 84 167 269 83 9380 9802 suspend20 800K 799979 90 172 290 78 8765 9404 suspend50 800K 800031 106 191 307 71 7945 8805 suspend200 800K 799905 182 307 411 62 6985 8242 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base 1000K 919543 3805 6390 14229 98 9324 7978 defer10 1000K 850751 4574 7382 15370 99 10218 8470 defer20 1000K 890296 4736 6862 14858 99 9708 8277 defer50 1000K 932694 3463 6180 13251 97 9148 8053 defer200 1000K 951311 3524 6052 13599 96 8875 7845 fullbusy 1000K 1000011 90 181 278 100 8731 10686 napibusy 1000K 1000050 93 184 280 100 8721 10547 suspend10 1000K 999962 101 193 306 92 8138 8980 suspend20 1000K 1000030 103 191 324 88 7844 8763 suspend50 1000K 1000001 114 202 320 83 7396 8431 suspend200 1000K 999965 185 314 428 76 6733 8072 testcase load qps avglat 95%lat 99%lat cpu cpq ipq base MAX 1005592 4651 6594 14979 100 8679 7918 defer10 MAX 928204 5106 7286 15199 100 9398 8380 defer20 MAX 984663 4774 6518 14920 100 8861 8063 defer50 MAX 1044099 4431 6368 14652 100 8350 7948 defer200 MAX 1040451 4423 6610 14674 100 8380 7931 fullbusy MAX 1236608 3715 3987 12805 100 7051 7936 napibusy MAX 1077516 4345 10155 15957 100 8080 7842 suspend10 MAX 1218344 3760 3990 12585 100 7150 7935 suspend20 MAX 1220056 3752 4053 12602 100 7150 7961 suspend50 MAX 1213666 3791 4103 12919 100 7183 7959 suspend200 MAX 1217411 3768 3988 12863 100 7161 7954 ~ FAQ - Can the new timeout value be threaded through the new epoll ioctl ? Only with difficulty. The epoll ioctl sets options on an epoll context and the NAPI ID associated with an epoll context can change based on what file descriptors a user app adds to the epoll context. This would introduce complexity in the API from the user perspective and also complexity in the kernel. - Can irq suspend be built by combining NIC coalescing and gro_flush_timeout ? No. The problem is that the long timeout must engage if and only if prefer-busy is active. When using NIC coalescing for the short timeout (without napi_defer_hard_irqs/gro_flush_timeout), an interrupt after an idle period will trigger softirq, which will run napi polling. At this point, prefer-busy is not active, so NIC interrupts would be re-enabled. Then it is not possible for the longer timeout to interject to switch control back to polling. In other words, only by using the software timer for the short timeout, it is possible to extend the timeout without having to reprogram the NIC timer or reach down directly and disable interrupts. Using gro_flush_timeout for the long timeout also has problems, for the same underlying reason. In the current napi implementation, gro_flush_timeout is not tied to prefer-busy. We'd either have to change that and in the process modify the existing deferral mechanism, or introduce a state variable to determine whether gro_flush_timeout is used as long timeout for irq suspend or whether it is used for its default purpose. In an earlier version, we did try something similar to the latter and made it work, but it ends up being a lot more convoluted than our current proposal. - Isn't it already possible to combine busy looping with irq deferral? Yes, in fact enabling irq deferral via napi_defer_hard_irqs and gro_flush_timeout is a precondition for prefer_busy_poll to have an effect. If the application also uses a tight busy loop with essentially nonblocking epoll_wait (accomplished with a very short timeout parameter), this is the fullbusy case shown in the results. An application using blocking epoll_wait is shown as the napibusy case in the result. It's a hybrid approach that provides limited latency benefits compared to the base case and plain irq deferral, but not as good as fullbusy or suspend. ~ Special thanks Several people were involved in earlier stages of the development of this mechanism whom we'd like to thank: - Peter Cai (CC'd), for the initial kernel patch and his contributions to the paper. - Mohammadamin Shafie (CC'd), for testing various versions of the kernel patch and providing helpful feedback. Thanks, Martin and Joe [1]: https://lore.kernel.org/netdev/20240812125717.413108-1-jdamato@fastly.com/ [2]: https://doi.org/10.1145/3626780 [3]: https://github.com/memcached/memcached/blob/master/doc/napi_ids.txt [4]: https://github.com/leverich/mutilate [5]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/mem… [6]: https://raw.githubusercontent.com/martinkarsten/irqsuspend/main/patches/lib… [7]: https://github.com/martinkarsten/irqsuspend [8]: https://github.com/martinkarsten/irqsuspend/tree/main/results v3: - Added Stanislav Fomichev's Acked-by to every patch except the newly added selftest. - Added Bagas Sanjaya's Reviewed-by to the documentation patch. - Fixed the commit message of patch 2 to remove a reference to the now non-existent sysfs setting. - Added a self test which tests both "regular" busy poll and busy poll with suspend enabled. This was added as patch 6 as requested by Paolo. netdevsim was chosen instead of veth due to netdevsim's pre-existing support for netdev-genl. See the commit message of patch 6 for more details. v2: https://lore.kernel.org/bpf/20241021015311.95468-1-jdamato@fastly.com/ - Cover letter updated, including a re-run of test data. - Patch 1 rewritten to use netdev-genl instead of sysfs. - Patch 3 updated with a comment added to napi_resume_irqs. - Patch 4 rebased to apply now that commit b9ca079dd6b0 ("eventpoll: Annotate data-race of busy_poll_usecs") has been picked up from VFS. - Patch 6 updated the kernel documentation. rfc -> v1: - Cover letter updated to include more details. - Patch 1 updated to remove the documentation added. This was moved to patch 6 with the rest of the docs (see below). - Patch 5 updated to fix an error uncovered by the kernel build robot. See patch 5's changelog for more details. - Patch 6 added which updates kernel documentation. Joe Damato (2): selftests: net: Add busy_poll_test docs: networking: Describe irq suspension Martin Karsten (5): net: Add napi_struct parameter irq_suspend_timeout net: Suspend softirq when prefer_busy_poll is set net: Add control functions for irq suspension eventpoll: Trigger napi_busy_loop, if prefer_busy_poll is set eventpoll: Control irq suspension for prefer_busy_poll Documentation/netlink/specs/netdev.yaml | 7 + Documentation/networking/napi.rst | 132 +++++++++- fs/eventpoll.c | 35 ++- include/linux/netdevice.h | 2 + include/net/busy_poll.h | 3 + include/uapi/linux/netdev.h | 1 + net/core/dev.c | 58 ++++- net/core/dev.h | 25 ++ net/core/netdev-genl-gen.c | 5 +- net/core/netdev-genl.c | 12 + tools/include/uapi/linux/netdev.h | 1 + tools/testing/selftests/net/.gitignore | 1 + tools/testing/selftests/net/Makefile | 2 + tools/testing/selftests/net/busy_poll_test.sh | 164 ++++++++++++ tools/testing/selftests/net/busy_poller.c | 245 ++++++++++++++++++ 15 files changed, 683 insertions(+), 10 deletions(-) create mode 100755 tools/testing/selftests/net/busy_poll_test.sh create mode 100644 tools/testing/selftests/net/busy_poller.c base-commit: 9e114ec8084020e10e1cb7b43dbbf6e69940866b -- 2.25.1

1 hour, 31 minutes

[PATCH v3] lib/math: Add int_sqrt test suite

by Luis Felipe Hernandez

Adds test suite for integer based square root function. The test suite is designed to verify the correctness of the int_sqrt() math library function. Signed-off-by: Luis Felipe Hernandez <luis.hernandez093(a)gmail.com> --- Changes in v2 - Add new line at the end of int_sqrt_kunit.c - Add explicit header includes for MODULE_* macros, strscpy, and ULONG_MAX Changes in v3 - Remove unnecesary new line after Kconfig entry for INT_SQRT_KUNIT_TEST - Correct int_sqrt instances with int_sqrt() in commit message and kconfig entry desc - Fix limits.h header include path --- lib/Kconfig.debug | 15 ++++++++++ lib/math/Makefile | 1 + lib/math/tests/Makefile | 1 + lib/math/tests/int_sqrt_kunit.c | 51 +++++++++++++++++++++++++++++++++ 4 files changed, 68 insertions(+) create mode 100644 lib/math/tests/int_sqrt_kunit.c diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 7312ae7c3cc5..c83f5dc9bb48 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2993,6 +2993,21 @@ config TEST_OBJPOOL If unsure, say N. +config INT_SQRT_KUNIT_TEST + tristate "Integer square root test test" if !KUNIT_ALL_TESTS + depends on KUNIT + default KUNIT_ALL_TESTS + help + This option enables the KUnit test suite for the int_sqrt() function, + which performs square root calculation. The test suite checks + various scenarios, including edge cases, to ensure correctness. + + Enabling this option will include tests that check various scenarios + and edge cases to ensure the accuracy and reliability of the square root + function. + + If unsure, say N + endif # RUNTIME_TESTING_MENU config ARCH_USE_MEMTEST diff --git a/lib/math/Makefile b/lib/math/Makefile index 3ef11305f8d2..25bcb968b369 100644 --- a/lib/math/Makefile +++ b/lib/math/Makefile @@ -9,3 +9,4 @@ obj-$(CONFIG_INT_POW_TEST) += tests/int_pow_kunit.o obj-$(CONFIG_TEST_DIV64) += test_div64.o obj-$(CONFIG_TEST_MULDIV64) += test_mul_u64_u64_div_u64.o obj-$(CONFIG_RATIONAL_KUNIT_TEST) += rational-test.o +obj-y += tests/ diff --git a/lib/math/tests/Makefile b/lib/math/tests/Makefile index 6a169123320a..e1a79f093b2d 100644 --- a/lib/math/tests/Makefile +++ b/lib/math/tests/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0-only obj-$(CONFIG_INT_POW_TEST) += int_pow_kunit.o +obj-$(CONFIG_INT_SQRT_KUNIT_TEST) += int_sqrt_kunit.o diff --git a/lib/math/tests/int_sqrt_kunit.c b/lib/math/tests/int_sqrt_kunit.c new file mode 100644 index 000000000000..3590142d2012 --- /dev/null +++ b/lib/math/tests/int_sqrt_kunit.c @@ -0,0 +1,51 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#include <kunit/test.h> +#include <linux/limits.h> +#include <linux/math.h> +#include <linux/module.h> +#include <linux/string.h> + +struct test_case_params { + unsigned long x; + unsigned long expected_result; + const char *name; +}; + +static const struct test_case_params params[] = { + { 0, 0, "edge-case: square root of 0" }, + { 4, 2, "perfect square: square root of 4" }, + { 81, 9, "perfect square: square root of 9" }, + { 2, 1, "non-perfect square: square root of 2" }, + { 5, 2, "non-perfect square: square root of 5"}, + { ULONG_MAX, 4294967295, "large input"}, +}; + +static void get_desc(const struct test_case_params *tc, char *desc) +{ + strscpy(desc, tc->name, KUNIT_PARAM_DESC_SIZE); +} + +KUNIT_ARRAY_PARAM(int_sqrt, params, get_desc); + +static void int_sqrt_test(struct kunit *test) +{ + const struct test_case_params *tc = (const struct test_case_params *)test->param_value; + + KUNIT_EXPECT_EQ(test, tc->expected_result, int_sqrt(tc->x)); +} + +static struct kunit_case math_int_sqrt_test_cases[] = { + KUNIT_CASE_PARAM(int_sqrt_test, int_sqrt_gen_params), + {} +}; + +static struct kunit_suite int_sqrt_test_suite = { + .name = "math-int_sqrt", + .test_cases = math_int_sqrt_test_cases, +}; + +kunit_test_suites(&int_sqrt_test_suite); + +MODULE_DESCRIPTION("math.int_sqrt KUnit test suite"); +MODULE_LICENSE("GPL"); -- 2.47.0

1 hour, 40 minutes

[PATCH net-next v8 00/24] Introducing OpenVPN Data Channel Offload

by Antonio Quartulli

This is the 8th version of the ovpn patchset. Thanks Sergey for arguing regarding splitting PEER_SET into SET and NEW. I decided to follow this suggestion as it makes the API and its return value easier to work with. Thanks Donald for the suggestions regarding the NL API - they have all been implemented (unless I forgot some, but hopefully I did not). Notable changes from v7: * Netlink API adjustments: ** renamed NL API from OP_OBJ to OBJ_OP (i.e. from SET_PEER to PEER_SET) ** split PEER_SET from PEER_NEW for better clarity in case of error ** renamed NL API from NEW/DEL_IFACE to DEV_NEW/DEL ** converted all underscores to dashes in YML NL spec ** split sockaddr_remote attr into ipv4/6, port and v6_scope_id attrs ** split local_ip attr into local_ipv4 and local_ipv6 attrs ** turned keyconf into a root attribute (it was nested in peer before) ** made key_swap use a keyconf object rather than a peer for consistency with key mgmt API ** created specific op for peer_del notification (peer_del_ntf) ** created specific op for key_swap notification (key_swap_ntf) ** allow user to update VPN IPv4/6 (peer is now rehashable) ** converted port attrs from u32 to u16 for better consistency with userspace code * added rtnl_ops .dellink implementation * removed patch 2 as it's not needed anymore thanks to the point above * moved rtnl_ops .kind initialization to first patch * updated MAINTAINERS file with Github tree and selftest folder * wrapped long lines in selftest scripts BONUS: used b4 for the first time to prepare the patchset and send it Please note that patches previously reviewed by Andrew Lunn have retained the Reviewed-by tag as they have been simply rebased without any modification. The latest code can also be found at: https://github.com/OpenVPN/linux-kernel-ovpn Thanks a lot! Best Regards, Antonio Quartulli OpenVPN Inc. --- Antonio Quartulli (24): netlink: add NLA_POLICY_MAX_LEN macro net: introduce OpenVPN Data Channel Offload (ovpn) ovpn: add basic netlink support ovpn: add basic interface creation/destruction/management routines ovpn: implement interface creation/destruction via netlink ovpn: keep carrier always on ovpn: introduce the ovpn_peer object ovpn: introduce the ovpn_socket object ovpn: implement basic TX path (UDP) ovpn: implement basic RX path (UDP) ovpn: implement packet processing ovpn: store tunnel and transport statistics ovpn: implement TCP transport ovpn: implement multi-peer support ovpn: implement peer lookup logic ovpn: implement keepalive mechanism ovpn: add support for updating local UDP endpoint ovpn: add support for peer floating ovpn: implement peer add/dump/delete via netlink ovpn: implement key add/del/swap via netlink ovpn: kill key and notify userspace in case of IV exhaustion ovpn: notify userspace when a peer is deleted ovpn: add basic ethtool support testing/selftest: add test tool and scripts for ovpn module Documentation/netlink/specs/ovpn.yaml | 387 +++++ MAINTAINERS | 11 + drivers/net/Kconfig | 15 + drivers/net/Makefile | 1 + drivers/net/ovpn/Makefile | 22 + drivers/net/ovpn/bind.c | 54 + drivers/net/ovpn/bind.h | 117 ++ drivers/net/ovpn/crypto.c | 172 ++ drivers/net/ovpn/crypto.h | 138 ++ drivers/net/ovpn/crypto_aead.c | 356 ++++ drivers/net/ovpn/crypto_aead.h | 31 + drivers/net/ovpn/io.c | 459 ++++++ drivers/net/ovpn/io.h | 25 + drivers/net/ovpn/main.c | 363 ++++ drivers/net/ovpn/main.h | 29 + drivers/net/ovpn/netlink-gen.c | 224 +++ drivers/net/ovpn/netlink-gen.h | 42 + drivers/net/ovpn/netlink.c | 1099 +++++++++++++ drivers/net/ovpn/netlink.h | 18 + drivers/net/ovpn/ovpnstruct.h | 60 + drivers/net/ovpn/packet.h | 40 + drivers/net/ovpn/peer.c | 1207 ++++++++++++++ drivers/net/ovpn/peer.h | 172 ++ drivers/net/ovpn/pktid.c | 130 ++ drivers/net/ovpn/pktid.h | 87 + drivers/net/ovpn/proto.h | 104 ++ drivers/net/ovpn/skb.h | 61 + drivers/net/ovpn/socket.c | 165 ++ drivers/net/ovpn/socket.h | 53 + drivers/net/ovpn/stats.c | 21 + drivers/net/ovpn/stats.h | 47 + drivers/net/ovpn/tcp.c | 506 ++++++ drivers/net/ovpn/tcp.h | 43 + drivers/net/ovpn/udp.c | 406 +++++ drivers/net/ovpn/udp.h | 26 + include/net/netlink.h | 1 + include/uapi/linux/ovpn.h | 116 ++ include/uapi/linux/udp.h | 1 + tools/net/ynl/ynl-gen-c.py | 2 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/net/ovpn/.gitignore | 2 + tools/testing/selftests/net/ovpn/Makefile | 18 + tools/testing/selftests/net/ovpn/config | 8 + tools/testing/selftests/net/ovpn/data-test-tcp.sh | 9 + tools/testing/selftests/net/ovpn/data-test.sh | 153 ++ tools/testing/selftests/net/ovpn/data64.key | 5 + tools/testing/selftests/net/ovpn/float-test.sh | 118 ++ tools/testing/selftests/net/ovpn/ovpn-cli.c | 1822 +++++++++++++++++++++ tools/testing/selftests/net/ovpn/tcp_peers.txt | 5 + tools/testing/selftests/net/ovpn/udp_peers.txt | 5 + 50 files changed, 8957 insertions(+) --- base-commit: 44badc908f2c85711cb18e45e13119c10ad3a05f change-id: 20241002-b4-ovpn-eeee35c694a2 Best regards, -- Antonio Quartulli <antonio(a)openvpn.net>

2 hours, 2 minutes

[RFC PATCH v3 0/6] Direct Map Removal for guest_memfd

by Patrick Roy

Unmapping virtual machine guest memory from the host kernel's direct map is a successful mitigation against Spectre-style transient execution issues: If the kernel page tables do not contain entries pointing to guest memory, then any attempted speculative read through the direct map will necessarily be blocked by the MMU before any observable microarchitectural side-effects happen. This means that Spectre-gadgets and similar cannot be used to target virtual machine memory. Roughly 60% of speculative execution issues fall into this category [1, Table 1]. This patch series extends guest_memfd with the ability to remove its memory from the host kernel's direct map, to be able to attain the above protection for KVM guests running inside guest_memfd. === Changes to v2 === - Handle direct map removal for physically contiguous pages in arch code (Mike R.) - Track the direct map state in guest_memfd itself instead of at the folio level, to prepare for huge pages support (Sean C.) - Allow configuring direct map state of not-yet faulted in memory (Vishal A.) - Pay attention to alignment in ftrace structs (Steven R.) Most significantly, I've reduced the patch series to focus only on direct map removal for guest_memfd for now, leaving the whole "how to do non-CoCo VMs in guest_memfd" for later. If this separation is acceptable, then I think I can drop the RFC tag in the next revision (I've mainly kept it here because I'm not entirely sure what to do with patches 3 and 4). === Implementation === This patch series introduces a new flag to the KVM_CREATE_GUEST_MEMFD that causes guest_memfd to remove its pages from the host kernel's direct map immediately after population/preparation. It also adds infrastructure for tracking the direct map state of all gmem folios inside the guest_memfd inode. Storing this information in the inode has the advantage that the code is ready for future hugepages extensions, where only removing/reinserting direct map entries for sub-ranges of a huge folio is a valid usecase, and it allows pre-configuring the direct map state of not-yet faulted in parts of memory (for example, when the VMM is receiving a RX virtio buffer from the guest). === Summary === Patch 1 (from Mike Rapoport) adds arch APIs for manipulating the direct map for ranges of physically contiguous pages, which are used by guest_memfd in follow up patches. Patch 2 adds the KVM_GMEM_NO_DIRECT_MAP flag and the logic for configuring direct map state of freshly prepared folios. Patches 3 and 4 mainly serve an illustrative purpose, to show how the framework from patch 2 can be extended with routines for runtime direct map manipulation. Patches 5 and 6 deal with documentation and self-tests respectively. [1]: https://download.vusec.net/papers/quarantine_raid23.pdf [RFC v1]: https://lore.kernel.org/kvm/20240709132041.3625501-1-roypat@amazon.co.uk/ [RFC v2]: https://lore.kernel.org/kvm/20240910163038.1298452-1-roypat@amazon.co.uk/ Mike Rapoport (Microsoft) (1): arch: introduce set_direct_map_valid_noflush() Patrick Roy (5): kvm: gmem: add flag to remove memory from kernel direct map kvm: gmem: implement direct map manipulation routines kvm: gmem: add trace point for direct map state changes kvm: document KVM_GMEM_NO_DIRECT_MAP flag kvm: selftests: run gmem tests with KVM_GMEM_NO_DIRECT_MAP set Documentation/virt/kvm/api.rst | 14 + arch/arm64/include/asm/set_memory.h | 1 + arch/arm64/mm/pageattr.c | 10 + arch/loongarch/include/asm/set_memory.h | 1 + arch/loongarch/mm/pageattr.c | 21 ++ arch/riscv/include/asm/set_memory.h | 1 + arch/riscv/mm/pageattr.c | 15 + arch/s390/include/asm/set_memory.h | 1 + arch/s390/mm/pageattr.c | 11 + arch/x86/include/asm/set_memory.h | 1 + arch/x86/mm/pat/set_memory.c | 8 + include/linux/set_memory.h | 6 + include/trace/events/kvm.h | 22 ++ include/uapi/linux/kvm.h | 2 + .../testing/selftests/kvm/guest_memfd_test.c | 2 +- .../kvm/x86_64/private_mem_conversions_test.c | 7 +- virt/kvm/guest_memfd.c | 280 +++++++++++++++++- 17 files changed, 384 insertions(+), 19 deletions(-) base-commit: 5cb1659f412041e4780f2e8ee49b2e03728a2ba6 -- 2.47.0

2 hours, 9 minutes

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror November 2024