Changes in linux

5569dd7d - kni: allow configuring thread granularity

Thu, 20 Jan 2022 12:00:00 +0000

kni: allow configuring thread granularityThe Kni kthreads seem to be re-scheduled at a granularity of roughly1 millisecond right now, which seems to be insufficient for performingtests involving a lot of control plane traffic.Even if KNI_KTHREAD_RESCHEDULE_INTERVAL is set to 5 microseconds, itseems that the existing code cannot reschedule at the desired granularily,due to precision constraints of schedule_timeout_interruptible().In our use case, we leverage the Linux Kernel for control plane, andit is not uncommon to have 60K - 100K pps for some signaling protocols.Since we are not in atomic context, the usleep_range() function seems to bemore appropriate for being able to introduce smaller controlled delays,in the range of 5-10 microseconds. Upon reading the existing code, it wouldseem that this was the original intent. Adding sub-millisecond delays,seems unfeasible with a call to schedule_timeout_interruptible().KNI_KTHREAD_RESCHEDULE_INTERVAL 5 /* us */schedule_timeout_interruptible( usecs_to_jiffies(KNI_KTHREAD_RESCHEDULE_INTERVAL));Below, we attempted a brief comparison between the existing implementation,which uses schedule_timeout_interruptible() and usleep_range().We attempt to measure the CPU usage, and RTT between two Kni interfaces,which are created on top of vmxnet3 adapters, connected by a vSwitch.insmod rte_kni.ko kthread_mode=single carrier=onschedule_timeout_interruptible(usecs_to_jiffies(5))kni_single CPU Usage: 2-4 %[root@localhost ~]# ping 1.1.1.2 -I eth1PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 eth1: 56(84) bytes of data.64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.70 ms64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.00 ms64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.99 ms64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.985 ms64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.00 msusleep_range(5, 10)kni_single CPU usage: 50%64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.338 ms64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.150 ms64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.123 ms64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.139 ms64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.159 msusleep_range(20, 50)kni_single CPU usage: 24%64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.202 ms64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.170 ms64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.171 ms64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.248 ms64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.185 msusleep_range(50, 100)kni_single CPU usage: 13%64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.537 ms64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.257 ms64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.231 ms64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.143 ms64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.200 msusleep_range(100, 200)kni_single CPU usage: 7%64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.716 ms64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.167 ms64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.459 ms64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.455 ms64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.252 msusleep_range(1000, 1100)kni_single CPU usage: 2%64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.22 ms64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.17 ms64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.17 ms64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.17 ms64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.15 msUpon testing, usleep_range(1000, 1100) seems roughly equivalent inlatency and cpu usage to the variant with schedule_timeout_interruptible(),while usleep_range(100, 200) seems to give a decent tradeoff betweenlatency and cpu usage, while allowing users to tweak the limits forimproved precision if they have such use cases.Disabling RTE_KNI_PREEMPT_DEFAULT, interestingly seems to lead to asoftlockup on my kernel.Kernel panic - not syncing: softlockup: hung tasksCPU: 0 PID: 1226 Comm: kni_single Tainted: G W O 3.10 #1 [] dump_stack+0x19/0x1b [] panic+0xcd/0x1e0 [] watchdog_timer_fn+0x160/0x160 [] __run_hrtimer.isra.4+0x42/0xd0 [] hrtimer_interrupt+0xe7/0x1f0 [] smp_apic_timer_interrupt+0x67/0xa0 [] apic_timer_interrupt+0x6d/0x80This patch also attempts to remove this option.References:[1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txtSigned-off-by: Tudor Cornea Acked-by: Padraig Connolly Reviewed-by: Ferruh Yigit List of files: /dpdk/kernel/linux/kni/kni_dev.h

ea6b39b5 - kni: remove ethtool support

Fri, 24 May 2019 16:00:00 +0000

kni: remove ethtool supportCurrent design requires kernel drivers and they need to be probed byLinux up to some level so that they can be usable by DPDK for ethtoolsupport, this requires maintaining the Linux drivers in DPDK.Also ethtool support is limited and hard, if not impossible, to expandto other PMDs.Since KNI ethtool support is not used commonly, if not used at all,removing the support for the sake of simplicity and maintenance.Signed-off-by: Ferruh Yigit Acked-by: Stephen Hemminger Acked-by: Neil Horman Acked-by: Thomas Monjalon List of files: /dpdk/kernel/linux/kni/Kbuild

c28e2165 - kni: fix build for SLES15-SP3

Tue, 19 Oct 2021 10:00:00 +0000

kni: fix build for SLES15-SP3As suse version numbering is inconsistent to determine Linux kernelAPI to be used. In this patch we check parameter of 'ndo_tx_timeout'API directly from the kernel source. This is done only for suse build.Bugzilla ID: 812Cc: stable@dpdk.orgSigned-off-by: Aman Singh Acked-by: Ferruh Yigit Tested-by: Longfeng Liang List of files: /dpdk/kernel/linux/kni/compat.h

a1b2558c - kni: restrict bifurcated device support

Tue, 23 Nov 2021 16:00:00 +0000

kni: restrict bifurcated device supportTo enable bifurcated device support, rtnl_lock is released before callinguserspace callbacks and asynchronous requests are enabled.But these changes caused more issues, like bug #809, #816. To reduce thescope of the problems, the bifurcated device support related changes areonly enabled when it is requested explicitly with new 'enable_bifurcated'module parameter.And bifurcated device support is disabled by default.So the bifurcated device related problems are isolated and they can befixed without impacting all use cases.Bugzilla ID: 816Fixes: 631217c76135 ("kni: fix kernel deadlock with bifurcated device")Cc: stable@dpdk.orgSigned-off-by: Ferruh Yigit Acked-by: Igor Ryzhov List of files: /dpdk/kernel/linux/kni/kni_net.c

d57f2899 - kni: fix freeing order in device release

Wed, 09 Feb 2022 07:00:00 +0000

kni: fix freeing order in device releaseThe "kni_dev" is the private data of the "net_device" in kni, and allocatedwith the "net_device" by calling "alloc_netdev()". The "net_device" isfreed by calling "free_netdev()" when kni release. The freed memoryincludes the "kni_dev". So after "kni_dev" should not be accessed after"net_device" is released.Fixes: e77fec694936 ("kni: fix possible mbuf leaks and speed up port release")Cc: stable@dpdk.orgKASAN trace:[ 85.263717] ==========================================================[ 85.264418] BUG: KASAN: use-after-free in kni_net_release_fifo_phy+ 0x30/0x84 [rte_kni][ 85.265139] Read of size 8 at addr ffff000260668d60 by task kni/341[ 85.265703][ 85.265857] CPU: 0 PID: 341 Comm: kni Tainted: G U O 5.15.0-rc4+ #1[ 85.266525] Hardware name: linux,dummy-virt (DT)[ 85.266968] Call trace:[ 85.267220] dump_backtrace+0x0/0x2d0[ 85.267591] show_stack+0x24/0x30[ 85.267924] dump_stack_lvl+0x8c/0xb8[ 85.268294] print_address_description.constprop.0+0x74/0x2b8[ 85.268855] kasan_report+0x1e4/0x200[ 85.269224] __asan_load8+0x98/0xd4[ 85.269577] kni_net_release_fifo_phy+0x30/0x84 [rte_kni][ 85.270116] kni_dev_remove.isra.0+0x50/0x64 [rte_kni][ 85.270630] kni_ioctl_release+0x254/0x320 [rte_kni][ 85.271136] kni_ioctl+0x64/0xb0 [rte_kni][ 85.271553] __arm64_sys_ioctl+0xdc/0x120[ 85.271955] invoke_syscall+0x68/0x1a0[ 85.272332] el0_svc_common.constprop.0+0x90/0x200[ 85.272807] do_el0_svc+0x94/0xa4[ 85.273144] el0_svc+0x78/0x240[ 85.273463] el0t_64_sync_handler+0x1a8/0x1b0[ 85.273895] el0t_64_sync+0x1a0/0x1a4[ 85.274264][ 85.274427] Allocated by task 341:[ 85.274767] kasan_save_stack+0x2c/0x60[ 85.275157] __kasan_kmalloc+0x90/0xb4[ 85.275533] __kmalloc_node+0x230/0x594[ 85.275917] kvmalloc_node+0x8c/0x190[ 85.276286] alloc_netdev_mqs+0x70/0x6b0[ 85.276678] kni_ioctl_create+0x224/0xf40 [rte_kni][ 85.277166] kni_ioctl+0x9c/0xb0 [rte_kni][ 85.277581] __arm64_sys_ioctl+0xdc/0x120[ 85.277980] invoke_syscall+0x68/0x1a0[ 85.278357] el0_svc_common.constprop.0+0x90/0x200[ 85.278830] do_el0_svc+0x94/0xa4[ 85.279172] el0_svc+0x78/0x240[ 85.279491] el0t_64_sync_handler+0x1a8/0x1b0[ 85.279925] el0t_64_sync+0x1a0/0x1a4[ 85.280292][ 85.280454] Freed by task 341:[ 85.280763] kasan_save_stack+0x2c/0x60[ 85.281147] kasan_set_track+0x2c/0x40[ 85.281522] kasan_set_free_info+0x2c/0x50[ 85.281930] __kasan_slab_free+0xdc/0x140[ 85.282331] slab_free_freelist_hook+0x90/0x250[ 85.282782] kfree+0x128/0x580[ 85.283099] kvfree+0x48/0x60[ 85.283402] netdev_freemem+0x34/0x44[ 85.283770] netdev_release+0x50/0x64[ 85.284138] device_release+0xa0/0x120[ 85.284516] kobject_put+0xf8/0x160[ 85.284867] put_device+0x20/0x30[ 85.285204] free_netdev+0x22c/0x310[ 85.285562] kni_dev_remove.isra.0+0x48/0x64 [rte_kni][ 85.286076] kni_ioctl_release+0x254/0x320 [rte_kni][ 85.286573] kni_ioctl+0x64/0xb0 [rte_kni][ 85.286992] __arm64_sys_ioctl+0xdc/0x120[ 85.287392] invoke_syscall+0x68/0x1a0[ 85.287769] el0_svc_common.constprop.0+0x90/0x200[ 85.288243] do_el0_svc+0x94/0xa4[ 85.288579] el0_svc+0x78/0x240[ 85.288899] el0t_64_sync_handler+0x1a8/0x1b0[ 85.289332] el0t_64_sync+0x1a0/0x1a4[ 85.289699][ 85.289862] The buggy address belongs to the object at ffff000260668000[ 85.289862] which belongs to the cache kmalloc-cg-8k of size 8192[ 85.291079] The buggy address is located 3424 bytes inside of[ 85.291079] 8192-byte region [ffff000260668000, ffff00026066a000)[ 85.292213] The buggy address belongs to the page:[ 85.292684] page:(____ptrval____) refcount:1 mapcount:0 mapping: 0000000000000000 index:0x0 pfn:0x2a0668[ 85.293585] head:(____ptrval____) order:3 compound_mapcount:0 compound_pincount:0[ 85.294305] flags: 0xbfff80000010200(slab|head|node=0|zone=2| lastcpupid=0x7fff)[ 85.295020] raw: 0bfff80000010200 0000000000000000 dead000000000122 ffff0000c000d680[ 85.295767] raw: 0000000000000000 0000000080020002 00000001ffffffff 0000000000000000[ 85.296512] page dumped because: kasan: bad access detected[ 85.297054][ 85.297217] Memory state around the buggy address:[ 85.297688] ffff000260668c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[ 85.298384] ffff000260668c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[ 85.299088] >ffff000260668d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[ 85.299781] ^[ 85.300396] ffff000260668d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[ 85.301092] ffff000260668e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb[ 85.301787] ===========================================================Signed-off-by: Huisong Li Signed-off-by: Min Hu (Connor) Acked-by: Ferruh Yigit List of files: /dpdk/kernel/linux/kni/kni_misc.c

7be78d02 - fix spelling in comments and strings

Mon, 29 Nov 2021 16:00:00 +0000

fix spelling in comments and stringsThe tool comes from https://github.com/jsorefSigned-off-by: Josh Soref Signed-off-by: Thomas Monjalon List of files: /dpdk/kernel/linux/kni/kni_fifo.h

e16b972b - build: remove deprecated Meson functions

Mon, 24 Jan 2022 17:00:00 +0000

build: remove deprecated Meson functionsStarting in meson 0.56, the functions meson.source_root() andmeson.build_root() are deprecated and to be replaced by the [moredescriptive] functions: project_source_root()/global_source_root() andproject_build_root()/global_build_root(). Unfortunately, these newreplacement functions were only added in 0.56 release too, so to usethem we would need version checks for old/new functions to remove thedeprecation warnings.However, the functions "current_build_dir()" and "current_source_dir()"remain unaffected by all this, so we can bypass the versioning problem,by saving off these values to "dpdk_source_root" and "dpdk_build_root"in the top-level meson.build fileBugzilla ID: 926Cc: stable@dpdk.orgSigned-off-by: Bruce Richardson Tested-by: Jerin Jacob List of files: /dpdk/kernel/linux/kni/meson.build