From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EA96BA0544; Wed, 12 Oct 2022 07:33:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DE3ED42D51; Wed, 12 Oct 2022 07:33:04 +0200 (CEST) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 5D87C40691 for ; Wed, 12 Oct 2022 07:33:03 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id 51D0BA0548; Wed, 12 Oct 2022 07:33:03 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [Bug 1101] [dpdk-22.11.0rc1][meson test] driver-tests/eventdev_selftest_sw test failed Date: Wed, 12 Oct 2022 05:33:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: meson X-Bugzilla-Version: 22.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: weiyuanx.li@intel.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org https://bugs.dpdk.org/show_bug.cgi?id=3D1101 Bug ID: 1101 Summary: [dpdk-22.11.0rc1][meson test] driver-tests/eventdev_selftest_sw test failed Product: DPDK Version: 22.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: meson Assignee: dev@dpdk.org Reporter: weiyuanx.li@intel.com Target Milestone: --- [Environment] DPDK version: Use make showversion or for a non-released version: git remot= e -v && git show-ref --heads dpdk22.11.0rc1 a74b1b25136a592c275afbfa6b70771469750aee Other software versions: name/version for QEMU, OVS, etc. Repeat as require= d. OS: Ubuntu 22.04.1 LTS (Jammy Jellyfish)/5.15.0-27-generic Compiler: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0 Hardware platform: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz NIC hardware: Ethernet Controller XXV710 for 25GbE SFP28 158b. NIC firmware:=C2=A0 driver: i40e version: 5.15.0-27-generic firmware-version: 9.00 0x8000cead 1.3179.0 [Test Setup] Steps to reproduce 1. Use the following command to build DPDK:=20 CC=3Dgcc meson -Denable_kmods=3DTrue -Dlibdir=3Dlib --default-library=3Dsta= tic x86_64-native-linuxapp-gcc/=20 ninja -C x86_64-native-linuxapp-gcc/=20 2. Execute the following command in the dpdk directory. =C2=A0 MALLOC_PERTURB_=3D204 DPDK_TEST=3Deventdev_selftest_sw /root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff [Show the output from the previous commands] root@dpdk-VF-dut247:~/dpdk# MALLOC_PERTURB_=3D204 DPDK_TEST=3Deventdev_self= test_sw /root/dpdk/x86_64-native-linuxapp-gcc/app/test/dpdk-test -c 0xff EAL: Detected CPU lcores: 72 EAL: Detected NUMA nodes: 2 EAL: Detected static linkage of DPDK EAL: Multi-process socket /var/run/dpdk/rte/mp_socket EAL: Selected IOVA mode 'VA' EAL: VFIO support initialized APP: HPET is not enabled, using TSC as default timer RTE>>eventdev_selftest_sw *** Running Single Directed Packet test... *** Running Directed Forward Credit test... *** Running Single Load Balanced Packet test... *** Running Unordered Basic test... *** Running Ordered Basic test... *** Running Burst Packets test... *** Running Load Balancing test... *** Running Prioritized Directed test... *** Running Prioritized Atomic test... *** Running Prioritized Ordered test... *** Running Prioritized Unordered test... *** Running Invalid QID test... *** Running Load Balancing History test... *** Running Inflight Count test... *** Running Abuse Inflights test... *** Running XStats test... *** Running XStats ID Reset test... 12: 1761: qid_0_port_2_pinned_flows value , expected 1 got 7 1778: qid_0_port_2_pinned_flows value incorrect, expected 1 got 7 ERROR - XStats ID Reset test FAILED. SW Eventdev Selftest Failed. Test Failed [Expected Result] Test ok. [Regression] Is this issue a regression: (Y/N) Y a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0 is the first bad commit commit a2833ecc5ea4adcbc3b77e7aeac2a6fd945da6a0 Author: Morten Br=C3=B8rup Date: =C2=A0 Fri Oct 7 13:44:50 2022 +0300 =C2=A0 =C2=A0 mempool: fix get objects from mempool with cache =C2=A0 =C2=A0 A flush threshold for the mempool cache was introduced in DPD= K version =C2=A0 =C2=A0 1.3, but rte_mempool_do_generic_get() was not completely upda= ted back =C2=A0 =C2=A0 then, and some inefficiencies were introduced. =C2=A0 =C2=A0 Fix the following in rte_mempool_do_generic_get(): =C2=A0 =C2=A0 1. The code that initially screens the cache request was not = updated =C2=A0 =C2=A0 with the change in DPDK version 1.3. =C2=A0 =C2=A0 The initial screening compared the request length to the cach= e size, =C2=A0 =C2=A0 which was correct before, but became irrelevant with the intr= oduction of =C2=A0 =C2=A0 the flush threshold. E.g. the cache can hold up to flushthres= h objects, =C2=A0 =C2=A0 which is more than its size, so some requests were not served= from the =C2=A0 =C2=A0 cache, even though they could be. =C2=A0 =C2=A0 The initial screening has now been corrected to match the ini= tial =C2=A0 =C2=A0 screening in rte_mempool_do_generic_put(), which verifies tha= t a cache =C2=A0 =C2=A0 is present, and that the length of the request does not overf= low the =C2=A0 =C2=A0 memory allocated for the cache. =C2=A0 =C2=A0 This bug caused a major performance degradation in scenarios = where the =C2=A0 =C2=A0 application burst length is the same as the cache size. In su= ch cases, =C2=A0 =C2=A0 the objects were not ever fetched from the mempool cache, reg= ardless if =C2=A0 =C2=A0 they could have been. =C2=A0 =C2=A0 This scenario occurs e.g. if an application has configured a = mempool =C2=A0 =C2=A0 with a size matching the application's burst size. =C2=A0 =C2=A0 2. The function is a helper for rte_mempool_generic_get(), so= it must =C2=A0 =C2=A0 behave according to the description of that function. =C2=A0 =C2=A0 Specifically, objects must first be returned from the cache, =C2=A0 =C2=A0 subsequently from the backend. =C2=A0 =C2=A0 After the change in DPDK version 1.3, this was not the behavi= or when =C2=A0 =C2=A0 the request was partially satisfied from the cache; instead, = the objects =C2=A0 =C2=A0 from the backend were returned ahead of the objects from the = cache. =C2=A0 =C2=A0 This bug degraded application performance on CPUs with a smal= l L1 cache, =C2=A0 =C2=A0 which benefit from having the hot objects first in the return= ed array. =C2=A0 =C2=A0 (This is probably also the reason why the function returns th= e objects =C2=A0 =C2=A0 in reverse order, which it still does.) =C2=A0 =C2=A0 Now, all code paths first return objects from the cache, subs= equently =C2=A0 =C2=A0 from the backend. =C2=A0 =C2=A0 The function was not behaving as described (by the function u= sing it) =C2=A0 =C2=A0 and expected by applications using it. This in itself is also= a bug. =C2=A0 =C2=A0 3. If the cache could not be backfilled, the function would a= ttempt =C2=A0 =C2=A0 to get all the requested objects from the backend (instead of= only the =C2=A0 =C2=A0 number of requested objects minus the objects available in th= e backend), =C2=A0 =C2=A0 and the function would fail if that failed. =C2=A0 =C2=A0 Now, the first part of the request is always satisfied from t= he cache, =C2=A0 =C2=A0 and if the subsequent backfilling of the cache from the backe= nd fails, =C2=A0 =C2=A0 only the remaining requested objects are retrieved from the b= ackend. =C2=A0 =C2=A0 The function would fail despite there are enough objects in t= he cache =C2=A0 =C2=A0 plus the common pool. =C2=A0 =C2=A0 4. The code flow for satisfying the request from the cache wa= s slightly =C2=A0 =C2=A0 inefficient: =C2=A0 =C2=A0 The likely code path where the objects are simply served from= the cache =C2=A0 =C2=A0 was treated as unlikely. Now it is treated as likely. =C2=A0 =C2=A0 Signed-off-by: Morten Br=C3=B8rup =C2=A0 =C2=A0 Signed-off-by: Andrew Rybchenko =C2=A0 =C2=A0 Reviewed-by: Morten Br=C3=B8rup =C2=A0lib/mempool/rte_mempool.h | 80 ++++++++++++++++++++++++++++++--------= --------- =C2=A01 file changed, 51 insertions(+), 29 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.=