From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 14BF7A0542
for <public@inbox.dpdk.org>; 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" <yidingx.zhou@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"Burakov, Anatoly" <anatoly.burakov@intel.com>,
"He, Xingguang" <xingguang.he@intel.com>, "stable@dpdk.org"
<stable@dpdk.org>, Stephen Hemminger <stephen@networkplumber.org>
References: <20220825072041.10768-1-yidingx.zhou@intel.com>
<20220906080511.46088-1-yidingx.zhou@intel.com>
<20220906075737.2fb429a5@hermes.local>
<DM5PR1101MB2107E5F7AD6AA2B0F227CF9D854F9@DM5PR1101MB2107.namprd11.prod.outlook.com>
<DM5PR1101MB210710482E74C30A41C536D5850D9@DM5PR1101MB2107.namprd11.prod.outlook.com>
<2ac0bac2-33d7-bcf2-3be2-af0ad98ecca2@amd.com>
<DM5PR1101MB2107028CEC02A59A8787071D85179@DM5PR1101MB2107.namprd11.prod.outlook.com>
From: Ferruh Yigit <ferruh.yigit@amd.com>
In-Reply-To: <DM5PR1101MB2107028CEC02A59A8787071D85179@DM5PR1101MB2107.namprd11.prod.outlook.com>
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 <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=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 <mailto:yidingx.zhou@intel.com> 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 <mailto:yidingx.zhou@intel.com>
>>>>>
>>>>>
>>>>> 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.