| ec487c18 | 22-Feb-2022 |
Megha Ajmera <[email protected]> |
sched: move grinder configuration
Grinder configuration is now moved to sched library.
Number of grinders can also modified by specifying
RTE_SCHED_PORT_N_GRINDERS=N in CFLAGS, where N is number of
sched: move grinder configuration
Grinder configuration is now moved to sched library.
Number of grinders can also modified by specifying
RTE_SCHED_PORT_N_GRINDERS=N in CFLAGS, where N is number of grinders.
Signed-off-by: Megha Ajmera <[email protected]>
Acked-by: Cristian Dumitrescu <[email protected]>
show more ...
|
| 5569dd7d | 20-Jan-2022 |
Tudor Cornea <[email protected]> |
kni: allow configuring thread granularity
The Kni kthreads seem to be re-scheduled at a granularity of roughly
1 millisecond right now, which seems to be insufficient for performing
tests involving
kni: allow configuring thread granularity
The Kni kthreads seem to be re-scheduled at a granularity of roughly
1 millisecond right now, which seems to be insufficient for performing
tests involving a lot of control plane traffic.
Even if KNI_KTHREAD_RESCHEDULE_INTERVAL is set to 5 microseconds, it
seems 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, and
it 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 be
more appropriate for being able to introduce smaller controlled delays,
in the range of 5-10 microseconds. Upon reading the existing code, it would
seem 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=on
schedule_timeout_interruptible(usecs_to_jiffies(5))
kni_single CPU Usage: 2-4 %
[root@localhost ~]# ping 1.1.1.2 -I eth1
PING 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 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.00 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.99 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.985 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.00 ms
usleep_range(5, 10)
kni_single CPU usage: 50%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.338 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.123 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.139 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.159 ms
usleep_range(20, 50)
kni_single CPU usage: 24%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.170 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.171 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.248 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.185 ms
usleep_range(50, 100)
kni_single CPU usage: 13%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.537 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.257 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.231 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.143 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.200 ms
usleep_range(100, 200)
kni_single CPU usage: 7%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.716 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.167 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.459 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.455 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=0.252 ms
usleep_range(1000, 1100)
kni_single CPU usage: 2%
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=2.22 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.17 ms
64 bytes from 1.1.1.2: icmp_seq=5 ttl=64 time=1.15 ms
Upon testing, usleep_range(1000, 1100) seems roughly equivalent in
latency and cpu usage to the variant with schedule_timeout_interruptible(),
while usleep_range(100, 200) seems to give a decent tradeoff between
latency and cpu usage, while allowing users to tweak the limits for
improved precision if they have such use cases.
Disabling RTE_KNI_PREEMPT_DEFAULT, interestingly seems to lead to a
softlockup on my kernel.
Kernel panic - not syncing: softlockup: hung tasks
CPU: 0 PID: 1226 Comm: kni_single Tainted: G W O 3.10 #1
<IRQ> [<ffffffff814f84de>] dump_stack+0x19/0x1b
[<ffffffff814f7891>] panic+0xcd/0x1e0
[<ffffffff810993b0>] watchdog_timer_fn+0x160/0x160
[<ffffffff810644b2>] __run_hrtimer.isra.4+0x42/0xd0
[<ffffffff81064b57>] hrtimer_interrupt+0xe7/0x1f0
[<ffffffff8102cd57>] smp_apic_timer_interrupt+0x67/0xa0
[<ffffffff8150321d>] apic_timer_interrupt+0x6d/0x80
This patch also attempts to remove this option.
References:
[1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
Signed-off-by: Tudor Cornea <[email protected]>
Acked-by: Padraig Connolly <[email protected]>
Reviewed-by: Ferruh Yigit <[email protected]>
show more ...
|
| d832326a | 21-Jan-2022 |
Bruce Richardson <[email protected]> |
build: fix warning about using -Wextra flag
Each build, meson would issue a warning reporting that the
"warning_level" setting should be used in place of adding -Wextra
directly to our build command
build: fix warning about using -Wextra flag
Each build, meson would issue a warning reporting that the
"warning_level" setting should be used in place of adding -Wextra
directly to our build commands. Testing with meson 0.61 shows that the
only difference for gcc and clang builds between warning levels 1 and
2 is the addition of -Wextra, so we can remove the warning by deleting
our explicit set of Wextra and changing the build defaults to
warning_level 2.
Fixes: 524a0d5d66b9 ("build: enable extra warnings with meson")
Signed-off-by: Bruce Richardson <[email protected]>
Acked-by: Luca Boccassi <[email protected]>
show more ...
|
| ab5ac1ad | 12-Nov-2021 |
Dmitry Kozlyuk <[email protected]> |
config/x86: fix MinGW cross build with Meson 0.49
Cross build with MinGW was broken for the baseline meson 0.49.2.
Cause: in c_args = '-mno-avx512f' from config/x86/cross-mingw,
each character was t
config/x86: fix MinGW cross build with Meson 0.49
Cross build with MinGW was broken for the baseline meson 0.49.2.
Cause: in c_args = '-mno-avx512f' from config/x86/cross-mingw,
each character was treated as a separate compiler option:
meson.build:4:0: ERROR: Compiler x86_64-w64-mingw32-gcc can not compile programs.
With c_args = ['-mno-avx512f'] configuration passed, but build failed,
because Meson placed -mno-avx512f after -mavx512f in CFLAGS:
In file included from /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/immintrin.h:55,
from /usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/x86intrin.h:32,
from ../dpdk/lib/net/net_crc_avx512.c:13:
/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/include/avx512fintrin.h:1650:1:
error: inlining failed in call to always_inline _mm512_ternarylogic_epi64:
target specific option mismatch
1650 | _mm512_ternarylogic_epi64 (__m512i __A, __m512i __B, __m512i __C,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
../dpdk/lib/net/net_crc_avx512.c:59:9: note: called from here
59 | return _mm512_ternarylogic_epi64(tmp0, tmp1, data_block, 0x96);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additionally, -m[no-]avx512f flag is expected to be in machine_args
by all the checks in meson.build files.
Commit 419c6e9af69e ("net/i40e: fix build for Windows MinGW")
fixed the errors cause by MinGW using AVX512F on Windows.
The binutils AVX512F bug check is now portable,
so enable it for Windows to switch AVX512 support on and off
without any special logic for MinGW.
Fixes: 549bfc83168f ("config: disable AVX512 with MinGW")
Signed-off-by: Dmitry Kozlyuk <[email protected]>
Acked-by: Bruce Richardson <[email protected]>
show more ...
|