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 263D0A04FD; Mon, 23 May 2022 10:43:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 174FB42685; Mon, 23 May 2022 10:43:42 +0200 (CEST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2085.outbound.protection.outlook.com [40.107.93.85]) by mails.dpdk.org (Postfix) with ESMTP id A2BF34161A for ; Mon, 23 May 2022 10:43:40 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mZtLdpgSgALzLJt3AMlRqkQsnA3MCvTvJ3XpwdhrA+lmJG2TDmpPUgmaxeJrXMADi+B7KWsFCb4TkTbOGcdSRij4mqq06JvtazpUqNurKeZp3QKpep0IPNZi+nCFcIvD5lI+c7CqL2L5ptdidA0ovaaZNCb0DnVdsSAQPOnspeCkFyb6mOWNlWs300BYCrjU48Q3iKKknDE2IJ8I97Z1r2kWfatK8Jhb2vu7TU3qa//pGCldjBFvRUTvd8PfkLcWjYwoOZIpALLSDgAlD8p2z2lVsyrmlBzhVzZKMyOCuDpskirDTTM+gw22eb7ZjWSwJIVFUJpv1Sh8KxOaIXTWZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ocjetsxasFORqlNsOrMAfLDAwZXHgHIE6iyV4XduT1o=; b=ezbXkNcMRi1amQj7keBqsfBUJyJlf+fdA97zFsZrOrYoWI1mcHdwzvr7F3RgGxpc2QCnyiLdbkAoT+q5Nze5qwJOyI5U8b/IXTagtZ2tY609Nc5ttaBtj7PSNLZt+QgNKvDqTU8UlK3jOjenDnydnB30x8lMEJLrB97yKF5H7heosJ8klE/YrWJqw3Eyqe6yLESTLom6HvMeqkt0t+Aua5V0udMf3r3I/epiX5i15+JHTezeSjvGhmzhhvxhe1kPjXvUxgYuHhSWh0Okpa1F1NRX8F/7APbl+npTgL7e4/wj84ET+DFBFgf8lijXC/LtyQ7yDnd37qFF6mbQHIFZMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 149.199.80.198) smtp.rcpttodomain=huawei.com smtp.mailfrom=amd.com; dmarc=fail (p=quarantine sp=quarantine pct=100) action=quarantine header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xilinx.onmicrosoft.com; s=selector2-xilinx-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ocjetsxasFORqlNsOrMAfLDAwZXHgHIE6iyV4XduT1o=; b=ffUBsVK9fa5h0thqmXzgn30ECR/0Hv8xtvJdZZtOqZ3zQfsX/kt4tHLIrPPs9KuptH1gubgaRCuOa6x+mSP7XY1n3V3vVw36jH4Dja46GI5vDVAzPlE4oUsm+Mx6hr3Uh9GBhkcN182Kp22NjVN3wEJu2MoYKs0sQMZRw71CKjU= Received: from BN6PR2001CA0035.namprd20.prod.outlook.com (2603:10b6:405:16::21) by BL0PR02MB4370.namprd02.prod.outlook.com (2603:10b6:208:42::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.22; Mon, 23 May 2022 08:43:37 +0000 Received: from BN1NAM02FT052.eop-nam02.prod.protection.outlook.com (2603:10b6:405:16:cafe::f6) by BN6PR2001CA0035.outlook.office365.com (2603:10b6:405:16::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.22 via Frontend Transport; Mon, 23 May 2022 08:43:37 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 149.199.80.198) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=fail action=quarantine header.from=amd.com; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning amd.com discourages use of 149.199.80.198 as permitted sender) Received: from xir-pvapexch02.xlnx.xilinx.com (149.199.80.198) by BN1NAM02FT052.mail.protection.outlook.com (10.13.2.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5273.14 via Frontend Transport; Mon, 23 May 2022 08:43:37 +0000 Received: from xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Mon, 23 May 2022 09:43:36 +0100 Received: from smtp.xilinx.com (172.21.105.197) by xir-pvapexch02.xlnx.xilinx.com (172.21.17.17) with Microsoft SMTP Server id 15.1.2176.14 via Frontend Transport; Mon, 23 May 2022 09:43:36 +0100 Envelope-to: fengchengwen@huawei.com, thomas@monjalon.net, dev@dpdk.org, xiaoyun.li@intel.com, aman.deep.singh@intel.com, yuying.zhang@intel.com, andrew.rybchenko@oktetlabs.ru Received: from [10.71.117.73] (port=27327) by smtp.xilinx.com with esmtp (Exim 4.90) (envelope-from ) id 1nt3f4-0002Jk-Nh; Mon, 23 May 2022 09:43:36 +0100 Message-ID: <80e9dc74-8747-1e9a-08ac-b198bf226cbb@amd.com> Date: Mon, 23 May 2022 09:43:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH] app/testpmd: remove invalid ports when other process detach Content-Language: en-US To: fengchengwen , Thomas Monjalon CC: , , , , Andrew Rybchenko References: <20220302023326.16509-1-fengchengwen@huawei.com> <5569707.V25eIC5XRa@thomas> <31263d7d-b880-ff29-70d9-2a8f75b0bb45@huawei.com> <80bdb6d3-8259-80b1-3733-ef19b6b4f840@amd.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 99937a93-5d79-4191-ab75-08da3c985444 X-MS-TrafficTypeDiagnostic: BL0PR02MB4370:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 2 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hwkJX3/g2FHBCIifuLaFqKeVgcVi6qGKKX0XOnSto+X0xrV8Cx7YX87sgPHbhtEsoTsZC+v5/OVavyo7EOUMVc44309JFZ+unYig1wKbAaDQq8e/MAu/XlSAjj4nFK5V7ojeOOkGNEK/BQ+KF3ldvJBkuCQXA1z2oGVx63l3F/A3Vt/v02pzf5Jk2B2CsOLa+xT2MAhHBXLj5Z7ryT3koq9DEgpANnXRfDuoWz8DJ5zdbg3D7VNO+vrXgizIo0Z/gF1v347AqrgY9C0LADuSqcvNklwbzcJZXiGDICjwBsem8OwufS+JrSxDrrZdNLPqw5TO9JVrO1uDNHicDoDrih0EWN3ctMOxLemd5Nws6gf+DV04rEUjMxUsbshCarPXa2ymxF8vNKfnZG+X2hDqUpFcYBqD2dRWwP23fj28rzu1Uc5K+w+uRKwpFPmXxk/wPyf4j0Bz8ww71wb80FGft4nDd7huz+lkTjfwUsBxk+ZZee1sM/b4UlYWqcHUiuDsd4Umua5RnE1HVaX5gItRfp9N/T9Z/EZOwBwcW79Mt4kevlIM2pq0umQDM08d6GAI5PVgv3jugCYM3vh73XzIljZJ+IxBcTK/WMdN5DzfjcGpNhBvbIU1XZhTM1wS4vEguKhrohA0eQDxJyXaxFX9Qias216UZHIwZAspxpSgU9+wvQ5EtTIERDekJMbFv2TCY6fuIHnAYZ4VOkIySicFvsHtAKciV3OM1qe64kA6ZD0= X-Forefront-Antispam-Report: CIP:149.199.80.198; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:xir-pvapexch02.xlnx.xilinx.com; PTR:unknown-80-198.xilinx.com; CAT:NONE; SFS:(13230001)(4636009)(40470700004)(46966006)(508600001)(9786002)(44832011)(53546011)(5660300002)(110136005)(7636003)(356005)(83380400001)(8936002)(26005)(6666004)(36756003)(54906003)(31686004)(316002)(82310400005)(336012)(31696002)(35950700001)(40460700003)(2906002)(47076005)(2616005)(4326008)(86362001)(70586007)(70206006)(8676002)(50156003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: xilinx.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 May 2022 08:43:37.0953 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99937a93-5d79-4191-ab75-08da3c985444 X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c; Ip=[149.199.80.198]; Helo=[xir-pvapexch02.xlnx.xilinx.com] X-MS-Exchange-CrossTenant-AuthSource: BN1NAM02FT052.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR02MB4370 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 On 5/21/2022 11:00 AM, fengchengwen wrote: > [CAUTION: External Email] > > Hi Ferruh, > > On 2022/5/20 23:05, Ferruh Yigit wrote: >> On 3/2/2022 8:36 AM, fengchengwen wrote: >>> On 2022/3/2 16:26, Thomas Monjalon wrote: >>>> 02/03/2022 03:33, Chengwen Feng: >>>>> Start main and secondary process: >>>>> ./dpdk-testpmd -a BDF0 -a BDF1 --proc-type=auto -- -i --rxq=8 --txq=8 >>>>> --num-procs=2 --proc-id=0 >>>>> ./dpdk-testpmd -a BDF0 -a BDF1 --proc-type=auto -- -i --rxq=8 --txq=8 >>>>> --num-procs=2 --proc-id=1 >>>>> Execute following command in main process: >>>>> port stop 0 >>>>> port detach 0 >>>>> Execute following command in secondary process: >>>>> set fwd mac >>>>> start >>>>> The secondary process will display: >>>>> Invalid port_id=0 >>>>> telcore 19 called rx_pkt_burst for not ready port 0 >>>>> stpmd> 8: [/lib64/libc.so.6(+0xdf600) [0xffff9e1dc600]] >>>>> 7: [/lib64/libpthread.so.0(+0x7c48) [0xffff9e28ac48]] >>>>> 6: [/usr/app/testpmd(eal_thread_loop+0x2c4) [0xb23574]] >>>>> 5: [/usr/app/testpmd() [0x9c21d8]] >>>>> 4: [/usr/app/testpmd() [0x9c2108]] >>>>> 3: [/usr/app/testpmd() [0x9b6cf0]] >>>>> 2: [/usr/app/testpmd() [0xad8620]] >>>>> 1: [/usr/app/testpmd(rte_dump_stack+0x20) [0xb1a130]] >>>>> >>>>> The root cause it that the secondary process has not removed invalid >>>>> ports when it processes RTE_ETH_EVENT_DESTROY event. >>>> >>>> Why the ports are not removed? >>> >> >> It is referring to application (testpmd) level state, ethdev port is removed. >> >> Above mentioned problem is valid since testpmd secondary process support is added. >> When primary hot remove a device, it updates relevant application state too, but for secondary process ethdev removes device without secondary process updating its state. >> >> I agree that using ethdev events is appropriate for this case, since action originated from ethdev for secondary process, need a way to notify application about it. >> Another option can be checking and removing invalid ports in secondary before each forwarding start, but since we already have an event for destroy, using it looks good to me. >> >> >>> Testpmd register function eth_event_callback to deal with DESTROY event, >>> currently it only assign ports[port_id].port_status with RTE_PORT_CLOSED, it >>> doesn't update other global variables like nb_ports. >>> >>>> >>>>> This patch adds a delay remove invalid ports invoke when process the >>>>> RTE_ETH_EVENT_DESTROY event. >>>> >>>> Why do we need this delay? >>> >>> The remove_invalid_ports will scan rte_eth_devices[], when process the DESTROY >>> event, the rte_eth_devices[x] still valid, so here we should a delay logic. >>> >> >> There is a dependency problem in the DESTROY event. >> >> We need some ethdev information to be able to deliver the event, so ethdev can't be completely destroyed until DESTROY event is processed. Which means when application received DESTROY event, ethdev is not fully destroyed yet. >> >> Except from above, 'remove_invalid_ports()' is called twice for primary process (as mentioned in commit log), this timer can be helping these two calls not conflict, but I am not sure if we can rely on a time for this. >> Since the problem is mainly for secondary process, assuming control commands like detaching a device will be called by primary process, so @Feng what do you think about adding a secondary process check to in the 'remove_invalid_ports_callback()' call? So 'remove_invalid_ports()' is called only once for primary process. > > If we execute following command in secondary process: > port stop 0 > port detach 0 > And execute following command in main process: > set fwd mac > start > The main process also show the same error. > I am aware you will get same error in that case, but how common is this to remove a device from secondary process? Also as mentioned above, what happens the 'remove_invalid_ports()' called both from remove path and event path at the same time? > So I think we should keep it. > >> >>>> >>>> [...] >>>>> +static void >>>>> +remove_invalid_ports_callback(void *arg) >>>>> +{ >>>>> + RTE_SET_USED(arg); >>>>> + remove_invalid_ports(); >>>>> +} >>>> [...] >>>>> case RTE_ETH_EVENT_DESTROY: >>>>> ports[port_id].port_status = RTE_PORT_CLOSED; >>>>> printf("Port %u is closed\n", port_id); >>>>> + if (rte_eal_alarm_set(100000, remove_invalid_ports_callback, >>>>> + (void *)(intptr_t)port_id)) >>>>> + fprintf(stderr, >>>>> + "Could not set up deferred device released\n"); >>>>> break; >>>> >>>> >>>> >>>> >>>> . >>>> >>> >> >> >> . >