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 14BF7A0542 for ; Fri, 2 Dec 2022 12:19:55 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E4CAB40687; Fri, 2 Dec 2022 12:19:54 +0100 (CET) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on2056.outbound.protection.outlook.com [40.107.96.56]) by mails.dpdk.org (Postfix) with ESMTP id 50146400D6; Fri, 2 Dec 2022 12:19:54 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hwATVWJg4wwVQ/X5zRYS3g1n0qo9jdQC7T5aEIKwRQdqn6yIikF8FipfISDRBehcO+NYC5gUMq+Xru7BXHG0PnQhEYsm1nrYCXAjgNk75fcuDv2g/3NTT3v828QXAOKWtBT2dHL72T27EJZHAMnG4siWJfqOcHZpFanoMt7BFBFBiOBMotw8tYhRaz/kN3h/M3nDkFFouAEIBGufllaQNeH3aDWVl7ZyIl69+tY291aThscXXLZkllPddQhsoia/U9zxcWdaM1C+FyM3yGVQ2BJzHLds6Gxv/cYI9OGGDiQyDo3Q52pUhN5Id9V6iC2Mlfh+ZA4I8G0aC4tAIrSPcQ== 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=b40kCEjzzxukJ0Awk0h+WOODlTeSIOmqQFC6tr4MKGw=; b=YHGDsPDBhm6VezNNsj9duRvLcTjUjsOxkW+nieDG1SjMhRRkPfoh6Q7rzCuRAb6iA4xAs2hjLmSQH7lmufrnXikw/WOln1fbomA+PoGJrTeYjQdtqAZBfc0KjxaCkJILOpfUiin/+UisihyOlLZmjKMzHjG3y57+z34JaYsiXtk2oDsEDw0xJ5XdCXEQh/EBSMk6vaB3G6rPXWoGIVQSycLlsCKpUvjD3aZbQ8iLfV60A8uNihzOy6RJHVc0kK71EeMz6ZDv7QliR3/kdl+iCyk3UFwphE4kbFplYl7FYw0uYGHnXpiSM71sY6A/xDwmnXOUZ3bjfQ4FDuiPzGwUlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b40kCEjzzxukJ0Awk0h+WOODlTeSIOmqQFC6tr4MKGw=; b=mWi/mOIakipqnEH9NkWj3swlaUo3vEkMdPkBjr2/DjWttSrVDuy7wOWsU9YBhnvpMC/dqJOfH+pJgggRbfuCl93+D3+/GR1bG80wTdbErvIj7crvGnzBWaiaCH/kRAxmnq5qzLK1BmOq3Ya8QooG9Uz03iWSh95SjJopdaE9ZPw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by BL1PR12MB5079.namprd12.prod.outlook.com (2603:10b6:208:31a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.10; Fri, 2 Dec 2022 11:19:50 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::b482:d5bd:c7d0:3842]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::b482:d5bd:c7d0:3842%9]) with mapi id 15.20.5880.008; Fri, 2 Dec 2022 11:19:50 +0000 Message-ID: <6b94e8ff-caa6-53e1-7810-1daf35cf9a7d@amd.com> Date: Fri, 2 Dec 2022 11:19:46 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v2] net/pcap: fix timeout of stopping device Content-Language: en-US To: "Zhou, YidingX" Cc: "dev@dpdk.org" , "Burakov, Anatoly" , "He, Xingguang" , "stable@dpdk.org" , Stephen Hemminger References: <20220825072041.10768-1-yidingx.zhou@intel.com> <20220906080511.46088-1-yidingx.zhou@intel.com> <20220906075737.2fb429a5@hermes.local> <2ac0bac2-33d7-bcf2-3be2-af0ad98ecca2@amd.com> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO3P123CA0008.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:ba::13) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|BL1PR12MB5079:EE_ X-MS-Office365-Filtering-Correlation-Id: 6b1b9532-d389-477c-2d41-08dad45720eb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v/BZdju/+/2N7EXFITybdVjTuGIpkyhE1JOo588IQjxPJC4UdJhjJbpBFkaYsqhSBy8mjvAeDKoPAeOUnchd+jOEE/i0EUFIjcUFeKCphSy5GeKPV2Btb7FtqC/uXCNZfRZdU11x0eMSskmrG5ZSZ1pkJLKzQeDGx+iGICkJ3IVPtNRQAZuwbHCMlLNRv5u9LPzNepfJKZz7Wv58VRytL4ZW3F8Eq3e5ck1tZSkwO8xruFDIMA9bo1cJio4tyck6lUtIegcsF0dDdWVHucW61eP3bkGPKhOQGwhp5b121kEAH307/XzZKvoq4yZjblOVeT4A/BTA1nOiQ0XkkWJGqq+17Y8A9s1kTY9TqMoQL3LWM/4InuDzY9OzPJzJfoNGcBno0YEXsaws6GvvXxR3dXvhINxpq4x4Tu61+MHtSEj7vc+9s25ZSYOkyPsb0cYwemGJAtkv0pA/+3hA97lZfxTtgh5dxWWYsEh10fYzvBrk8dyJJHLOuvOeGD3544uejQt6O2VwiGRL545qso5QMuo93iMdRy2kgNYYy/f95W0H+XrrFJcjzNXfbj8fVaK0i7+Kc3jRAV78JU4lf2eQTw4aZf1/GZkQje43mzNsCy9HU7mwvWRfGCx+R3/rNlKkVotyIZJ71ltHFnGG70ZU6ZtumAcs/MLRS6I3lZmZwPCbxwxJjGr4lZGcZluZuE1hOJGIQkLIyPoSuwM4Dct7v4/D6nOheLWTwCGZkhx/oR0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(451199015)(36756003)(38100700002)(31696002)(86362001)(316002)(31686004)(6512007)(54906003)(6916009)(8676002)(66556008)(66476007)(478600001)(6486002)(66946007)(6666004)(6506007)(26005)(186003)(53546011)(2906002)(83380400001)(2616005)(41300700001)(4326008)(44832011)(5660300002)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bVQvbWcvQnF6Mm1Tc3UrZk1zNDZ1akF3WHI3aTdIdmJMQWJMZHB3cWtYNGg0?= =?utf-8?B?ZlZ2alFZQ0ZYMVppVGQ2cktIR2pFZXRiUXlGbGoyREw2SlFNYVh6TVNidDJX?= =?utf-8?B?NG5CQ0hSd0p3ek5yM0x5MDlBWUtsdXlEU21nNHJhUTAzdyt0bmtsZ0xTRysy?= =?utf-8?B?MUwzeGcwYXkyMWpBR24wZmljbU53d2NCenM4aHhsSllxQW1OdERKalN3cUV5?= =?utf-8?B?ZTcrdVg1TUFiSm0vYktMMWN2T3J4K09uZTFCYmxtR0pNZG5GTHRuMzdaeVhp?= =?utf-8?B?dVc5RXpDcHJaMGV2S0FMZWVLaDRVQVgxbC96TWVGTkxPbjZKaytFdTdnSmlZ?= =?utf-8?B?Q2Q4VXpiT2pJUUNNZjRXNGkxakhnYS9IeGJZUGZKYlRZZTVxb1V2bElObjdn?= =?utf-8?B?RkxXaERnZlRJakc4YktUTkVvZWo0OGZ0anBUMkNOQk90TGF6VjQ0WXErU29r?= =?utf-8?B?aVlCcWxRem5mYnoxdmlmOWUvSVIrK3JxYWZYb2YrVWcwMDdYU2hlR2VPcEpE?= =?utf-8?B?c2JtdzhsMnZuMnVndm54dXNBODUrQ0xMN2sreUlLU3BFN09venZFbGRIN29s?= =?utf-8?B?Rzg3aENwaXVoVDZKT0h6VXNTeE5ub3JtQytzaGtlNDlsc2g3MC9LbmY2WVhV?= =?utf-8?B?QkVyVmd3d24vdmR6NEczWUFQZ21McWc0UEVQdFRLTXhhaWN3cHhDUzlOL1dQ?= =?utf-8?B?QXI0aFhPRzFNK0l3c1piN0dqeXZiMStPbG1oWjUzbVE0c1gxYmJoekphYmFJ?= =?utf-8?B?bkJzamdhNHY0OXMyZ1BIODE1Nm5jaXlPeFovdG1rVUlOQk5CYnB2SnRGZEVu?= =?utf-8?B?UzFDZ0M1TGdQNWZsMm05WW1OMjJLSlIvbThtZmp0bTBBWHhxdlJ2LzBEc25i?= =?utf-8?B?N1ZUblRSWWQrYWdreWF5UGlFVDl5VHFSVHFjVlBrYW8rRnB2Z0E1SWxEL0hC?= =?utf-8?B?eXlNeDhsaHRXUTVYUTVSY0xKMHhoVWczNFQwdkQ1dm9hN3FqWGpqNDRRT21M?= =?utf-8?B?MWtCMHVsSGprZGk3L09GKyt6TU9mOXQxOWlvTUFTRkdvaW1KTWlRU0FsODk5?= =?utf-8?B?Q0RiNzZqbG1wQnYzZ2NzS3pmUm5XZGpQU0tmaXpuV2ZIdElZdU1zQ091Y0cy?= =?utf-8?B?N2ZPMUR6VzZkTldMV1grdlYrVWp6M3BYb1lsVWxXQU9xREpwcFJ3dGxycjZt?= =?utf-8?B?UTZBUWs5d2lOOGZ4b0huZHRkV3RmQyt4d2QxUmJBdW81anNtUVd2YVhaV2pm?= =?utf-8?B?b1FRNHVYRWt1VjVmRXpzRGdnbUEwSHRVQkQxaWYvK3hFVXRDV0svbWE0TkxG?= =?utf-8?B?M2hhb2x3bjlEd0RWNGhGalJtc1RWeGpPSkxhU1dYZW1aVE9mMHptMUVzV2V5?= =?utf-8?B?OHkvZ2szeXBvbFV6NlhzQ1dsR25PWi9VRXR0cGxTTy9Ud2JpbFdpNDJuc3Qz?= =?utf-8?B?VjB0bWt6bittbVVucHBOY1BpTHFvWjJMUEtZRVJ3Y2lDelVDc1RLVWhZYWx6?= =?utf-8?B?VHdkMTVKSDRqZ0E4Y0hBL2dOcEJwSERhSGVON2YxckhnbytzZzdpUVllRG9R?= =?utf-8?B?ZTRoejdMOTVsam84ODg5L0xyYk9vTTZacVN6UkthWkR5K3RDMUpvWTJ6QXhu?= =?utf-8?B?c1QxUDdEemNrMjJiYVJsNUkxLzFST3ExOFlQcGRzS0Y4dG5QbDhCaFNjRGZr?= =?utf-8?B?clZjZmJYMmNUZC9GSlJjdEtwRVhmclBNbzJRNUpOZkl0R3ltb3FHSlFWOE9z?= =?utf-8?B?Q2pZbWxIZzREdkNCL2pMekU4WWlGUVA4N0hqZzllaklPT1JnVEVKMWNxM1pR?= =?utf-8?B?aEFyLzdqNmxQUVRzb3ZKTm5uMng1azZWSTlIZCtHM09GQVRpV3JpRWhYcmNk?= =?utf-8?B?TFk1c1pIQ0JLOGZ5Mzl2eDl4K0ZHOUpuS2UyaXdZUmRNQVJUdnVvNWVoZW0v?= =?utf-8?B?Wit3ei9hYXA3T1RzaTNzeklPVk84WUN4aXRCWnpoQUJhUHZEaVFnVDN3bHNp?= =?utf-8?B?SVR5Sk45bDNPSHZPdnRSZHhyTkw5R29hWTdWd1JGaFF6Z0EwK2Q1czE2SHF6?= =?utf-8?B?enpCVm5GMFhFOUJGREFGRDkzWkR0OUpZNWZLSGU2RkdMOWtYMWgweFBjcXZl?= =?utf-8?Q?jLO6FmjpySGJVzrSZAiWQIppi?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b1b9532-d389-477c-2d41-08dad45720eb X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Dec 2022 11:19:50.7591 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JLlwpLtANg1yFBCUb1qmdh78+TwrL/ppBLQVMAl1V8iyGmeD+ZEa4oe9116xWyGR X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5079 X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org On 12/2/2022 10:13 AM, Zhou, YidingX wrote: > > >>>>> On Tue, 6 Sep 2022 16:05:11 +0800 >>>>> Yiding Zhou wrote: >>>>> >>>>>> The pcap file will be synchronized to the disk when stopping the device. >>>>>> It takes a long time if the file is large that would cause the >>>>>> 'detach sync request' timeout when the device is closed under >>>>>> multi-process scenario. >>>>>> >>>>>> This commit fixes the issue by using alarm handler to release dumper. >>>>>> >>>>>> Fixes: 0ecfb6c04d54 ("net/pcap: move handler to process private") >>>>>> Cc: mailto:stable@dpdk.org >>>>>> >>>>>> Signed-off-by: Yiding Zhou >>>>> >>>>> >>>>> I think you need to redesign the handshake if this the case. >>>>> Forcing 30 second delay at the end of all uses of pcap is not acceptable. >>>> >>>> @Zhang, Qi Z Do we need to redesign the handshake to fix this? >>> >>> Hi, Ferruh >>> Sorry for the late reply. >>> I did not receive your email on Oct 6, I got your comments from patchwork. >>> >>> "Can you please provide more details on multi-process communication >>> and call trace, to help us think about a solution to address this >>> issue in a more generic way (not just for pcap but for any case device >>> close takes more than multi-process timeout)?" >>> >>> I try to explain this issue with a sequence diagram, hope it can be displayed >> correctly in the mail. >>> >>> thread intr thread intr thread thread >>> of secondary of secondary of primary of primary >>> | | | | >>> | | | | >>> rte_eal_hotplug_remove >>> rte_dev_remove >>> eal_dev_hotplug_request_to_primary >>> rte_mp_request_sync ------------------------------------------------------->| >>> | >>> >> handle_secondary_request >>> |<-----------------| >>> | >>> __handle_secondary_request >>> eal_dev_hotplug_request_to_secondary >>> |<------------------------------------- rte_mp_request_sync >>> | >>> handle_primary_request--------->| >>> | >>> __handle_primary_request >>> local_dev_remove(this will take long time) >>> rte_mp_reply -------------------------------->| >>> | >>> local_dev_remove >>> |<------------------------------------------------- >>> rte_mp_reply >>> >>> The marked 'local_dev_remove()' in the secondary process will perform a >> pcap file synchronization operation. >>> When the pcap file is too large, it will take a lot of time (according to my test >> 100G takes 20+ seconds). >>> This caused the processing of hot_plug message to time out. >> >> Hi Yiding, >> >> Thanks for the information, >> >> Right now all MP operations timeout is hardcoded in the code and it is 5 >> seconds. >> Do you think does it work to have an API to set custom timeout, something like >> `rte_mp_timeout_set()`, and call this from pdump? >> >> This gives a generic solution for similar cases, not just for pcap. >> But my concern is if this is too much multi-process related internal detail to >> update, @Anatoly may comment on this. > > Hi, Ferruh > For pdump case only, I think the timeout is affected by pcap's size and other system components, such as the type of FS, system memory size. > It may be difficult to predict the specific time value for setting. It doesn't have to be specific. Point here is to have a multi process API to set timeout, instead of put a hardcoded timeout in pcap PMD.