From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0068.outbound.protection.outlook.com [104.47.36.68]) by dpdk.org (Postfix) with ESMTP id 7F7CC3772 for ; Tue, 9 Jan 2018 08:12:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CAVIUMNETWORKS.onmicrosoft.com; s=selector1-cavium-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U5ivHTiwHKFNOYgJ/GpKM1NmExCNuQbg105mkXxqIe0=; b=ZmzzRJZ/7x9aKVPNhVQEPY6APgZPHp+BwheZx1IoEPUkNiRAKYxo60qF6ZneBM0u5onaJ9nZapPB5YC0VDG6tOc7f3b1dUBQh0DIT/qJiCc/+WnStSEjARrHoX4pUT2FxOP/VD8LzMqMxdDwBcBQNqU7W7+WltGScT2HYMpw5to= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Pavan.Bhagavatula@cavium.com; Received: from Pavan-LT (103.16.71.47) by MWHPR07MB3469.namprd07.prod.outlook.com (10.164.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Tue, 9 Jan 2018 07:12:25 +0000 Date: Tue, 9 Jan 2018 12:42:06 +0530 From: Pavan Nikhilesh To: "Eads, Gage" , "Van Haaren, Harry" , "jerin.jacob@caviumnetworks.com" , "santosh.shukla@caviumnetworks.com" Cc: dev@dpdk.org Message-ID: <20180109071205.sd7uonyldp3k6k6o@Pavan-LT> References: <1512011314-19682-1-git-send-email-gage.eads@intel.com> <1512011314-19682-2-git-send-email-gage.eads@intel.com> <20180108153219.jszoepdgfiggn3bm@Pavan-LT> <20180108160529.gven7vlrbmrrlw2p@Pavan-LT> <9184057F7FC11744A2107296B6B8EB1E369CDE01@fmsmsx101.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E369CDE01@fmsmsx101.amr.corp.intel.com> User-Agent: NeoMutt/20170609 (1.8.3) X-Originating-IP: [103.16.71.47] X-ClientProxiedBy: HK2PR04CA0088.apcprd04.prod.outlook.com (10.170.154.160) To MWHPR07MB3469.namprd07.prod.outlook.com (10.164.192.20) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d1c73621-f361-49d3-d930-08d55730570c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:MWHPR07MB3469; X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 3:Gl8/Zh7JSgFo0365GB0cvfpNGu8Y4IMQxTIZu8GpHI7usZKn5gDGTNngE+dv+B2ixVC3AsIClqY0tokzut+ENJ063r5gsOQXgreF6CVU0KedE+B93x8Lrjj/ObBn+yLvYnEZPql1GmlqyEBP+tP3t+ACiImBRLFezvchoCWRnuoCltM3h+zJpDE/Qynyx2zcMpAedCWWtxvdHpFE7MgmmEmhDLX6F6/YQePZFxrAvGytxQdYlr5QnSZ/8BntLUbl; 25:a1oN1E3rmOUgkMgo2pYI0mDDSuZfTe+ed13KFqKoH4PRmJbCfYJa7j/z4dkBg6HowoqUE+79INGBHtfJLZUrNDIHH+muReVsH/wIrv9hNV/FmVpgdUI1Kp7yeEKLHA3pAWHrBpvZWtLs+56tyLId+2eUR3vLf9mS6PT/arytbhjSub/bmRcVa4/PNT0K5+aHFhLXvLhRYPwfq2eM43g3fIwTzAtVoz/IgQeR+yTogRY9h+sxE5Wr4geK4s0d2TMXpUdS9iwQDo71UXTLT690ekyk7Aehezl55h+YeWCFxEc4tUK4Aj7yZwLIfC6Mau3y+cZKQH2o7u/EXzuNZcteyA==; 31:ybOW37bTnIBKxpq2GK3TIq2Pv+PaiprQKs5psp6cmMBk7iw45yufjbm8H81CpbcYwHKh7CoUuXhaRIL1r10vc03EO5cuOaLJMq8tysJBP/Q958+k+34SfB+uthnWRd5icKZwwkNFjvyeSwmYpLqaavrw31ZO8ygD8fQ+RnDxCGzbgSFoITvNovLZfLwswTMUmiHDoXQ3Lt/biy58danVzDRn3yiZpsnctbElqwmCmEM= X-MS-TrafficTypeDiagnostic: MWHPR07MB3469: X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 20:vmdM4hHMzEkOx+Kuy21g0Nyyw2bug01GLbIeQg4yDLX4xlwik/PpFnLU6R+doUFCgO7crFBHXtmt4MYmdUPMBBQ07ArlN8vxHx4JjAcQSj0dbW9863P68kRi1wQNxJlPIphf89Zbo9GryRbOl5eHhSQQ6p6zZYntZYy6fQAF0VBmS4pMSPTq2xYxucxSmTAnM7c5XRSrUQNQp84nbnFMTJP9ueLkp/d+O595JrRpRGwNd4XHMHsCilcDQxymdsAoA5j0N+D2n7kUy/XpGpiIGx7E5nzBmWtR8NuL++KK0DiJvETARRWV61nPWV5G94iryAlVjNvEBvn1hFpAACtl4lOO/JXm5Mb7wqDgtq4uJ/XNudu3k5LQLQmoR7Ptj12Rk6s777Nbb3TiU6SoJt3yQ4CtcxK+Zv54m0g0AJwc693KasvuQ+Io511+/cTmlqW9Um823QlI1mubvsiY+5LTRHsJFCh/VsoX3ZINx+s20RiIN8/Cbr/XCfgJ6ZkhIVOLe2o4Ihp9en80sHd51Qr/cXQ0DZvaFg1Pv3RWqA4OziEl+nZxIqVnl04LuYqA9WYQv7sXo6fbhjTYqH81tuTO3o+SnnLNoItr8UE+Kj2mYu4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(211171220733660)(228905959029699); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(6041268)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR07MB3469; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR07MB3469; X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 4:NrWlIjio+vkc+ZXcCGhpYhTs/CcRStcsQh3DkWr9t9mwxbD+wVPV5Zr9h199sjv9vSD3FNyyH4Ufg1OTex6ph2X+QUG6IDt3F82FTfpxsv/B9h+QfGCMaikRRwhYUrMgbrntCWUFAD2dP6BxwMB3GHTr+0Jwh0OcX74knIV6EpSUopNf/K+v8tv4L643o71Jm8AuU/lmDnCwp910o7037yTAhz3YYW5Nqf/qFELNQdT6FkCCUDneBOYsKxeZIG3HiGNcscAdEQnWYqwmRChqQTodjwGJpWhLHWbFQqpvjR0BADEowFJxjdO7v6qISY/J04GdduRFQIR36mf8YTDs/KhvEvFBLDZTJvtRYAAfQpg= X-Forefront-PRVS: 0547116B72 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(396003)(39860400002)(346002)(376002)(24454002)(199004)(189003)(13464003)(55674003)(51914003)(93886005)(58126008)(83506002)(81156014)(81166006)(110136005)(316002)(50466002)(2501003)(68736007)(16586007)(8936002)(33716001)(47776003)(66066001)(16526018)(53376002)(25786009)(2201001)(966005)(4326008)(106356001)(5660300001)(105586002)(6246003)(6496006)(575784001)(53546011)(386003)(59450400001)(52116002)(9686003)(76176011)(2950100002)(42882006)(53936002)(33896004)(6636002)(6666003)(97736004)(6306002)(305945005)(7736002)(1076002)(6116002)(23726003)(8676002)(3846002)(2906002)(229853002)(72206003)(55016002)(478600001)(107986001)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR07MB3469; H:Pavan-LT; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cavium.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MWHPR07MB3469; 23:DYUIdYF6QxXZm/lAbGDxsI0yyIuAk0LmPv+V5udXW?= =?us-ascii?Q?QLV/H566eMyLwRT/vQKiXLLrrIjc8XTBK2W6Z4nhcHVo0zv+birJ+6jomtSy?= =?us-ascii?Q?G1FrcyZsuKrmXZnTmTv02SMRTr7so41mlHOOME22wXCUHgGbTAt7Zgevb1he?= =?us-ascii?Q?vmFkQlTL4Y9Na7EQW+TnABwzJtM36qYw4iwuw0Do1xKHUNDjx5PKAogSUO76?= =?us-ascii?Q?k39tEU497ZxP8FWnzLXBLbJZDg2NGtJHErcIlg9iukTHvdQVvFAFKMdwg2S3?= =?us-ascii?Q?ZfXHmpcbbHIX8SaiOG4bV6tGv5Iql2SeEUJ1cij7+GA//o0TcxfU1ijeRaNJ?= =?us-ascii?Q?AiX6ZITMn06AcrVn9IlOXxg2aRc1ywsQW9aQOgHgPEkfj44ra0CO1ZV5zjtE?= =?us-ascii?Q?4J0Kn6nmxBC+HVIizmsiKHOFf/S07dymNB3QMZx9LJTwe7J35GfooejTGKez?= =?us-ascii?Q?cVjp8JQ1XIovYkJNgCXX/bwMaQCSesr95hSrA1JK7EYfbKNUWuhDI67twhh6?= =?us-ascii?Q?7G3spcbUIfnZNIs1JMTE5g4oc5w6fuNT1KDJKZ1jFjeAzh77A6fPLcyKdzQN?= =?us-ascii?Q?I22fi8f9hXUs9Rp/4pCzIGK02iS4EIda4qCz/R5SDiQzDH3IyzxKGKa75uOi?= =?us-ascii?Q?aIi5EGZmrRzs0xKhsDNvAx8B8KT+RImX8/gu8bH6ZbegHwWaqvhIF9ZQd4a+?= =?us-ascii?Q?33fZ8XSHl2okWy7vE0tS4yrkf3PFe4VL5uvId/6BvvXdOm4iStkXIQd+iuI1?= =?us-ascii?Q?WFd2TlhsfGiubi9xmO+EY+NAQGi8fuUyvkTfGOUtgQAucTpu0WOn+sMU5UsT?= =?us-ascii?Q?2T/+0NraL9/7OUCqkIJlDhAL5LNGdrF0bogTkGcUqzjGQ+VJ+RLCM3xddehq?= =?us-ascii?Q?re2WyFaCMlS2a4fe9rUPBJIt7OOWWYqShtNKPOjAI52YCWwsfGDW8gEO0bCN?= =?us-ascii?Q?wwiBfVJCeSYwRiXGcqeAJ93qLELhRSqfLJNT9yaGOzIUKENg+h1tHcXRhuNh?= =?us-ascii?Q?r5LI8xALg1bJ/pDn/0sxBhpPtRbvzcpdIHP9MKz9ad1ppJU8uXYG9CQLYZU2?= =?us-ascii?Q?aWtfEV0nucR5jaFhtr24DF/AzcYpGrOVyvWNK6bNx3yCnznxoeGBalTqALTC?= =?us-ascii?Q?NmXg+ccHwivBE2hC0F477WcKSbr8nKcnFLHjFuGCy8XC5WBnMstty0/SOABH?= =?us-ascii?Q?28IWeXLrEvUHVBj/Qm9laKtb7YjVT5rfgwMfadVk2xa1rdFdm2wNo7/Yp40j?= =?us-ascii?Q?rcQkeZU7g7zReNb5Vt3zL1ELMPKj7QWjKqg8VChdpYkDtjuZrf7DVRHo2hPw?= =?us-ascii?Q?Ec2AiObEVrtSOElR7fz5IMlPR6khrojqy0oSopfYyaxb7IG4y1jF2IoIsZSA?= =?us-ascii?Q?touyMwvWUJCWVYyzR40yEfyEgFaxzZH9WLIdkq7cvTgEjqnHDObIOWuVe/nK?= =?us-ascii?Q?iYJprAFR05XGX7tr6V9eIr13MAcmea4dDd2gnzH8/J/vIWraLxEUZf6wD9LW?= =?us-ascii?Q?JlHvNUB+Lz/VT1nFuwrNt13fVyrtuPdMwY=3D?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR07MB3469; 6:v4knLX6klAQtfwYj4rvrilkwUwJoJ4mGft0wusKmEhi2bTnlf+9TaCI9vad3ek3CkcNHl9dp2ANixAYwJa0qeAYSQMeaPqKT2NckWCoYdolOfIJIZYmBB/a4gry3GYF+6aVo9ibm+zVoe8cLDSPIb/mlzltJl/cHwTx696UhqioNkmJLc9M0lExgj5oMlQME3+mvif5ClGFlzHibGbYci66/+K9ozQ9wurszaIe84ic/Wu8vOiDIU9KJ667joqzK3H0kXezh+G91L8SbsGi0F036tnsm5p/I63hWxipa6IEmF+i9qwPX660Kf9q4U0pyj9Dwil7/M/DPLTExqKk1A2lHgmBDt6xUWX3QJLmERkA=; 5:lHuk3XhlOGnTxyNKXMfBQbw1GBdSB9Su3EZLaRIbsExHagh59kR3giB7E+E5yCjNhZBdz+wttwr8ZLYa/lk06Ca4a2Aw3PMWxnkbP1Xj2NQosNN/je7+YUFEEGwOTnZVENN+8hn9xrT+fRNc+X/7XJN0XH7Wvu4m5Al12hSrsWk=; 24:hOoe+ikatxipjkX6uJnwyuUTEw0dvRk37U4xKh0wvgpv5wA9LTjnfwcdDpr5S7b/pXk+32w+BIiLsQJTxGh/MiUEWglYRf6Q/p2e6y7NEk4=; 7:VD/aQbwmAI7wEZsHEgma/x7Wlkn38KaPzmEpKfbZwa0BB6pbIK3NEUcZbAlJcAWewCboeN9snRKH0Pi6TOC4udtyY09jCZheY06RxqQOIV2FY+wAIVrNR/Nwg7BHekWlsg+TNduuYzPhtguPCVQ9yqDq3sWHxuDXwrVLODq1lqPgWQja/ULWvWrLD4N1UDuQNIwc0r+JoeBBls3y4x3dwoNz1011KhnI2e7FxyrmO+jVjs3uINvhfOczUfQOE6RR SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2018 07:12:25.7049 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1c73621-f361-49d3-d930-08d55730570c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 711e4ccf-2e9b-4bcf-a551-4094005b6194 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR07MB3469 Subject: Re: [dpdk-dev] [PATCH 2/2] event/sw: use dynamically-sized IQs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 07:12:30 -0000 Hi Gage, On Mon, Jan 08, 2018 at 06:36:36PM +0000, Eads, Gage wrote: > Hi Pavan, > > Thanks for the report and the GDB output. We've reproduced this and traced it down to how the PMD (mis)handles the re-configuration case. When the SW PMD is reconfigured, it reallocates the IQ chunks and reinitializes the chunk freelist, but it doesn't delete the stale pointers in sw->qids[*].iq. This causes multiple references to the same IQ memory to exist in the system, eventually resulting in the segfault. > Ah, that explains why it only happens in case of Rx adapter as first eventdev is created and then based on the ethernet device caps (RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT) the event device is stopped and reconfigured. > I expect a proper fix will take us a day or two, but in the meantime the following change should fix the segfault ***for your specific usage only***: > I will use this while verifying example/eventdev_pipeline rework patchset. > diff --git a/drivers/event/sw/sw_evdev.c b/drivers/event/sw/sw_evdev.c > index 1ef6340..01da538 100644 > --- a/drivers/event/sw/sw_evdev.c > +++ b/drivers/event/sw/sw_evdev.c > @@ -436,7 +436,7 @@ sw_dev_configure(const struct rte_eventdev *dev) > > /* If this is a reconfiguration, free the previous IQ allocation */ > if (sw->chunks) > - rte_free(sw->chunks); > + return 0; > > sw->chunks = rte_malloc_socket(NULL, > sizeof(struct sw_queue_chunk) * > > Mulling over the fix raises a question that the documentation is unclear on. If the user sends events into an eventdev, then calls rte_event_dev_stop() -> rte_event_dev_configure() -> rte_event_dev_start(), is the eventdev required to maintain any previously queued events? I would expect not. However, if the user calls calls rte_event_dev_stop() -> rte_event_queue_setup() -> rte_event_dev_start() (i.e. it is an additive reconfiguration), it seems more reasonable that the other event queues would maintain their contents. I'd imagine this is also hardware/device-dependent. > I think it's entirely implementation dependent and when rte_event_dev_stop() is invoked we need not guarantee the state of previously queued events. > Thanks, > Gage Thanks, Pavan > > > -----Original Message----- > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com] > > Sent: Monday, January 8, 2018 10:06 AM > > To: Van Haaren, Harry ; Eads, Gage > > ; jerin.jacob@caviumnetworks.com; > > santosh.shukla@caviumnetworks.com > > Cc: dev@dpdk.org > > Subject: Re: [PATCH 2/2] event/sw: use dynamically-sized IQs > > > > On Mon, Jan 08, 2018 at 03:50:24PM +0000, Van Haaren, Harry wrote: > > > > From: Pavan Nikhilesh [mailto:pbhagavatula@caviumnetworks.com] > > > > Sent: Monday, January 8, 2018 3:32 PM > > > > To: Eads, Gage ; Van Haaren, Harry > > > > ; jerin.jacob@caviumnetworks.com; > > > > santosh.shukla@caviumnetworks.com > > > > Cc: dev@dpdk.org > > > > Subject: Re: [PATCH 2/2] event/sw: use dynamically-sized IQs > > > > > > > > On Wed, Nov 29, 2017 at 09:08:34PM -0600, Gage Eads wrote: > > > > > This commit introduces dynamically-sized IQs, by switching the > > > > > underlying data structure from a fixed-size ring to a linked list of queue > > 'chunks.' > > > > > > > > > > > > > Sw eventdev crashes when used alongside Rx adapter. The crash > > > > happens when pumping traffic at > 1.4mpps. This commit seems responsible > > for this. > > > > > > > > > > > > Apply the following Rx adapter patch > > > > http://dpdk.org/dev/patchwork/patch/31977/ > > > > Command used: > > > > ./build/eventdev_pipeline_sw_pmd -c 0xfffff8 --vdev="event_sw" -- > > > > -r0x800 > > > > -t0x100 -w F000 -e 0x10 > > > > > > Applied the patch to current master, recompiled; cannot reproduce here.. > > > > > master in the sense dpdk-next-eventdev right? > > > Is it 100% reproducible and "instant" or can it take some time to occur there? > > > > > It is instant > > > > > > > Backtrace: > > > > > > > > Thread 4 "lcore-slave-4" received signal SIGSEGV, Segmentation fault. > > > > [Switching to Thread 0xffffb6c8f040 (LWP 25291)] > > > > 0x0000aaaaaadcc0d4 in iq_dequeue_burst (count=48, ev=0xffffb6c8dd38, > > > > iq=0xffff9f764720, sw=0xffff9f332600) at > > > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:14 > > > > 2 > > > > 142 ev[total++] = current->events[index++]; > > > > > > Could we get the output of (gdb) info locals? > > > > > > > Thread 4 "lcore-slave-4" received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xffffb6c8f040 (LWP 19751)] > > 0x0000aaaaaadcc0d4 in iq_dequeue_burst (count=48, ev=0xffffb6c8dd38, > > iq=0xffff9f764620, sw=0xffff9f332500) at > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:142 > > 142 ev[total++] = current->events[index++]; > > > > (gdb) info locals > > next = 0x7000041400be73b > > current = 0x7000041400be73b > > total = 36 > > index = 1 > > (gdb) > > > > > > Noticed an other crash: > > > > Thread 4 "lcore-slave-4" received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0xffffb6c8f040 (LWP 19690)] > > 0x0000aaaaaadcfb78 in iq_alloc_chunk (sw=0xffff9f332500) at > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:63 > > 63 sw->chunk_list_head = chunk->next; > > > > (gdb) info locals > > chunk = 0x14340000119 > > > > (gdb) bt > > #0 0x0000aaaaaadcfb78 in iq_alloc_chunk (sw=0xffff9f332500) at > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:63 > > #1 iq_enqueue (ev=0xffff9f3967c0, iq=0xffff9f764620, sw=0xffff9f332500) at > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:95 > > #2 __pull_port_lb (allow_reorder=0, port_id=5, sw=0xffff9f332500) at > > /root/clean/rebase/dpdk-next- > > eventdev/drivers/event/sw/sw_evdev_scheduler.c:463 > > #3 sw_schedule_pull_port_no_reorder (sw=0xffff9f332500, port_id=5) at > > /root/clean/rebase/dpdk-next- > > eventdev/drivers/event/sw/sw_evdev_scheduler.c:486 > > #4 0x0000aaaaaadd0608 in sw_event_schedule (dev=0xaaaaaafbd200 > > ) at > > /root/clean/rebase/dpdk-next- > > eventdev/drivers/event/sw/sw_evdev_scheduler.c:554 > > #5 0x0000aaaaaadca008 in sw_sched_service_func (args=0xaaaaaafbd200 > > ) at > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/sw_evdev.c:767 > > #6 0x0000aaaaaab54740 in rte_service_runner_do_callback (s=0xffff9fffdf80, > > cs=0xffff9ffef900, service_idx=0) at > > /root/clean/rebase/dpdk-next- > > eventdev/lib/librte_eal/common/rte_service.c:349 > > #7 0x0000aaaaaab54868 in service_run (i=0, cs=0xffff9ffef900, > > service_mask=18446744073709551615) at > > /root/clean/rebase/dpdk-next- > > eventdev/lib/librte_eal/common/rte_service.c:376 > > #8 0x0000aaaaaab54954 in rte_service_run_iter_on_app_lcore (id=0, > > serialize_mt_unsafe=1) at > > /root/clean/rebase/dpdk-next- > > eventdev/lib/librte_eal/common/rte_service.c:405 > > #9 0x0000aaaaaaaef04c in schedule_devices (lcore_id=4) at > > /root/clean/rebase/dpdk-next- > > eventdev/examples/eventdev_pipeline_sw_pmd/main.c:223 > > #10 0x0000aaaaaaaef234 in worker (arg=0xffff9f331c80) at > > /root/clean/rebase/dpdk-next- > > eventdev/examples/eventdev_pipeline_sw_pmd/main.c:274 > > #11 0x0000aaaaaab4382c in eal_thread_loop (arg=0x0) at > > /root/clean/rebase/dpdk-next- > > eventdev/lib/librte_eal/linuxapp/eal/eal_thread.c:182 > > #12 0x0000ffffb7e46d64 in start_thread () from /usr/lib/libpthread.so.0 > > #13 0x0000ffffb7da8bbc in thread_start () from /usr/lib/libc.so.6 > > > > > > > > > > > > > > (gdb) bt > > > > #0 0x0000aaaaaadcc0d4 in iq_dequeue_burst (count=48, > > > > ev=0xffffb6c8dd38, iq=0xffff9f764720, sw=0xffff9f332600) at > > > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/iq_chunk.h:14 > > > > 2 > > > > #1 sw_schedule_atomic_to_cq (sw=0xffff9f332600, qid=0xffff9f764700, > > > > iq_num=0, > > > > count=48) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/drivers/event/sw/sw_evdev_scheduler.c:74 > > > > #2 0x0000aaaaaadcdc44 in sw_schedule_qid_to_cq (sw=0xffff9f332600) > > > > at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/drivers/event/sw/sw_evdev_scheduler.c:262 > > > > #3 0x0000aaaaaadd069c in sw_event_schedule (dev=0xaaaaaafbd200 > > > > ) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/drivers/event/sw/sw_evdev_scheduler.c:564 > > > > #4 0x0000aaaaaadca008 in sw_sched_service_func (args=0xaaaaaafbd200 > > > > ) at > > > > /root/clean/rebase/dpdk-next-eventdev/drivers/event/sw/sw_evdev.c:76 > > > > 7 > > > > #5 0x0000aaaaaab54740 in rte_service_runner_do_callback > > > > (s=0xffff9fffdf80, cs=0xffff9ffef900, service_idx=0) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/lib/librte_eal/common/rte_service.c:349 > > > > #6 0x0000aaaaaab54868 in service_run (i=0, cs=0xffff9ffef900, > > > > service_mask=18446744073709551615) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/lib/librte_eal/common/rte_service.c:376 > > > > #7 0x0000aaaaaab54954 in rte_service_run_iter_on_app_lcore (id=0, > > > > serialize_mt_unsafe=1) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/lib/librte_eal/common/rte_service.c:405 > > > > #8 0x0000aaaaaaaef04c in schedule_devices (lcore_id=4) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/examples/eventdev_pipeline_sw_pmd/main.c:223 > > > > #9 0x0000aaaaaaaef234 in worker (arg=0xffff9f331d80) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/examples/eventdev_pipeline_sw_pmd/main.c:274 > > > > #10 0x0000aaaaaab4382c in eal_thread_loop (arg=0x0) at > > > > /root/clean/rebase/dpdk-next- > > > > eventdev/lib/librte_eal/linuxapp/eal/eal_thread.c:182 > > > > #11 0x0000ffffb7e46d64 in start_thread () from > > > > /usr/lib/libpthread.so.0 > > > > #12 0x0000ffffb7da8bbc in thread_start () from /usr/lib/libc.so.6 > > > > > > > > Segfault seems to happen in sw_event_schedule and only happens under > > > > high traffic load. > > > > > > I've added -n 0 to the command line allowing it to run forever, and > > > after ~2 mins its still happily forwarding pkts at ~10G line rate here. > > > > > > > On arm64 the crash is instant even without -n0. > > > > > > > > > Thanks, > > > > Pavan > > > > > > Thanks for reporting - I'm afraid I'll have to ask a few questions to identify why > > I can't reproduce here before I can dig in and identify a fix. > > > > > > Anything special about the system that it is on? > > > > Running on arm64 octeontx with 8x10G connected. > > > > > What traffic pattern is being sent to the app? > > > > Using something similar to trafficgen, IPv4/UDP pkts. > > > > 0:00:51 958245 |0xB00 2816|0xB10 2832|0xB20 2848|0xB30 > > 2864|0xC00 * 3072|0xC10 * 3088|0xC20 * 3104|0xC30 * 3120| Totals > > Port Status |XFI30 Up|XFI31 Up|XFI32 Up|XFI33 Up|XFI40 > > Up|XFI41 Up|XFI42 Up|XFI43 Up| > > 1:Total TX packets | 7197041566| 5194976604| 5120240981| 4424870160| > > 5860892739| 5191225514| 5126500427| 4429259828|42545007819 > > 3:Total RX packets | 358886055| 323055411| 321000948| 277179800| > > 387486466| 350278086| 348080242| 295460613|2661427621 > > 6:TX packet rate | 0| 0| 0| 0| 0| 0| 0| > > 0| 0 > > 7:TX octet rate | 0| 0| 0| 0| 0| 0| 0| > > 0| 0 > > 8:TX bit rate, Mbps | 0| 0| 0| 0| 0| 0| 0| > > 0| 0 > > 10:RX packet rate | 0| 0| 0| 0| 0| 0| 0| > > 0| 0 > > 11:RX octet rate | 0| 0| 0| 0| 0| 0| 0| > > 0| 0 > > 12:RX bit rate, Mbps | 0| 0| 0| 0| 0| 0| > > 0| 0| 0 > > 36:tx.size | 60| 60| 60| 60| 60| 60| 60| > > 60| > > 37:tx.type | IPv4+UDP| IPv4+UDP| IPv4+UDP| IPv4+UDP| > > IPv4+UDP| IPv4+UDP| IPv4+UDP| IPv4+UDP| > > 38:tx.payload | abc| abc| abc| abc| abc| abc| > > abc| abc| > > 47:dest.mac | fb71189c0| fb71189d0| fb71189e0| fb71189bf| > > fb7118ac0| fb7118ad0| fb7118ae0| fb7118abf| > > 51:src.mac | fb71189bf| fb71189cf| fb71189df| fb71189ef| > > fb7118abf| fb7118acf| fb7118adf| fb7118aef| > > 55:dest.ip | 11.1.0.99| 11.17.0.99| 11.33.0.99| 11.0.0.99| 14.1.0.99| > > 14.17.0.99| 14.33.0.99| 14.0.0.99| > > 59:src.ip | 11.0.0.99| 11.16.0.99| 11.32.0.99| 11.48.0.99| 14.0.0.99| > > 14.16.0.99| 14.32.0.99| 14.48.0.99| > > 73:bridge | off| off| off| off| off| off| > > off| off| > > 77:validate packets | off| off| off| off| off| off| > > off| off| > > > > Thanks, > > Pavan. > > > > > > > > Thanks > > > > > > > > > > > >