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 D2E17A0542; Fri, 2 Dec 2022 11:22:15 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6A35342D15; Fri, 2 Dec 2022 11:22:15 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id 26900400D6; Fri, 2 Dec 2022 11:22:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669976533; x=1701512533; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1WhkHEDFtDOHiWNT56yVG0GmmdupsfbaRNtemrAKDJY=; b=Rv1vncjLTPxQ6LxEYRkZdytc+gsN/VOSmsakPGRUucY4FsjZWs1DA0Pa v5w7PSCWGs9R75Nkt+VjSXiyWu3CTPCixDDeEh4XACHJtgqnqTJlw9So8 HqVQnC0r1MVot9EmwDT9pHbSQuX4X3ITyUwpOtsM3iKGi1ziDMVioC9bz W9uhp8Q0rg8ApAi8RCesIwh3cVJYuCmGOHx4XFN+oYsBm0vmhXyiUt6z2 KtGsXhK9gfNxMwVqCFmKszjyGCzesgtGzuKwzs9wdducw7x/lABo7FxV+ naDM6sm2qdpqRFEYAO0pB0qhnOnx9sL1DAs1TciSCPqeV5fKJe3jZJqzj A==; X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="314629003" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="314629003" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Dec 2022 02:22:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10548"; a="647119746" X-IronPort-AV: E=Sophos;i="5.96,212,1665471600"; d="scan'208";a="647119746" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga007.fm.intel.com with ESMTP; 02 Dec 2022 02:22:12 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16; Fri, 2 Dec 2022 02:22:11 -0800 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.16 via Frontend Transport; Fri, 2 Dec 2022 02:22:11 -0800 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.101) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.16; Fri, 2 Dec 2022 02:22:11 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LniMj1E/a3C+uHn5X3BNdFaqwi+nomG6w2cGDhAfXTU8HXpmXNGe0ysUovw2UPsF81xc9TQjZ6kh43QoGyS9QycG5rV2IHiL3VSyWx8y/Oyzjek8m4+6ilXmFSbCxcjX5+dTn5jokNaYMGKFXGAIEgI3uBkT8/1g+aUa+MeLZsFO4joTk6FqP9gcJBeR8SRLjrt+jf+H5lUIoCc7DfqMCvH6UmUWhtflhQAiI8+Qp8hC7TjfRAvp1jPECAthsU89iU1hY/7oA3rM3dsud02b0uxMeAFKjaWZYcX03rVazcJmICOkcQ6yKdZWOlNfd511TO+DeIgKBPH1bqDnIH7PKw== 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=mHY2R76cCpOzRPS6tVPgUplAnHKrzGoGX8MrqZJAiB4=; b=XqEP/+tLzgT9/StW2f2C9ECAbQ71huUvpmrJ7mdQah9TNyFZGZ2KQF88b5BeOEdYNUHotCvBrmymdT1Cm9NDjYfDwpaFQv+dIWFOYQG6LJSYdOZE3e7FB+G/nSi50Haq4Xk80xa7uv3ErobhKYTdaboJyQjGCmslq8RabeJkiQNm0Gj8ED5WAembW0n5XXuv/rBEjzydc1/PNAw4uAvwBeQF/iCicfqatt0PM7gCULy1VYyF5KIxA06JCVQiU7BGwXaJnNKemVhBSPzyiBl/aTjp4DzOPliH9KiCR3Gy+qg9FC2v47vM/yl5IYk2ZiSfjhzgSvwhC0v1YHwKRUdf1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM5PR1101MB2107.namprd11.prod.outlook.com (2603:10b6:4:5a::19) by CH0PR11MB5540.namprd11.prod.outlook.com (2603:10b6:610:d7::19) 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 10:22:10 +0000 Received: from DM5PR1101MB2107.namprd11.prod.outlook.com ([fe80::41d0:d6c9:62b2:177d]) by DM5PR1101MB2107.namprd11.prod.outlook.com ([fe80::41d0:d6c9:62b2:177d%9]) with mapi id 15.20.5880.008; Fri, 2 Dec 2022 10:22:10 +0000 From: "Zhou, YidingX" To: Stephen Hemminger CC: "ferruh.yigit@amd.com" , "dev@dpdk.org" , "Burakov, Anatoly" , "He, Xingguang" , "stable@dpdk.org" Subject: RE: [PATCH v2] net/pcap: fix timeout of stopping device Thread-Topic: [PATCH v2] net/pcap: fix timeout of stopping device Thread-Index: AQHYwcctL9bFJ76KRUKNwgs+pLJ9gK3SfnOAgBcQh8CAYZCroIAAjJmAgA8+7qA= Date: Fri, 2 Dec 2022 10:22:10 +0000 Message-ID: References: <20220825072041.10768-1-yidingx.zhou@intel.com> <20220906080511.46088-1-yidingx.zhou@intel.com> <20220906075737.2fb429a5@hermes.local> <20221122092857.53a50b2e@hermes.local> In-Reply-To: <20221122092857.53a50b2e@hermes.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM5PR1101MB2107:EE_|CH0PR11MB5540:EE_ x-ms-office365-filtering-correlation-id: 5ce4394e-aaa7-433f-b8f5-08dad44f124f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BaHAkwheeuEWhQXDAFscunWewJI+FLDyg9LTyQcoZLDIPuUcB2rHBhVwVow3DaI0WatLNNz+jI0y5BbsGxBdJOpEbhs2uIb7j6bdIKb8RwWxIzWsRKFGapDYPij93Yn6dWL4i2U1dMXXw0VpoUgOKp7yfHPApgJTHmVz+CQ+3RY3IvVl3RFBpPiIrzEtK4la6CuKI6tvJIp6zsdaCT/kj/8mEeepATEpQskf1yCfAs2WvvyOKhpWc7ztc1yVDMdC/tonhCnN/CxhRsaGfGbQjIF2LS2qWzu8RpDyx89wL/HWP+aIizdQnQmvFH34hV3KPUAL8H6/jRJSK0rQ0RCV2G7S9AQerKCi8Zfubg6jMpMqfX6UzbTajoNgbBh+xuJOn5jUEbbgR9DoFLRFMECodtte7UjJW/EYDIsxTC1PipxzmRbY72UamXNR2EVMfyif2Iz7EpIRZVWBL4/92W215CYO8wJzUCWIUcm5cEOoOIw6Zgh9FWxR9Nmpn+WWibrVMx4oZdiZk84T2rXVQ947Bd9ciKvLrnRAUA6Yzz7Zn7V1JakvK9/oE8sBlmEZ2dlEnTMwUb5vzeXv7spp1jzWtg9qmEc64LB/pKPfnh1hT9gefjOr8j2s3hxkHXd2v6UT9Adh02ZRykTtu8LM/wZQtiJtz0kAPf4TqCYDOeiVEfSktG3gAxO3CAxeUNhyVvJJWca0Pur+roY6qyIfcmMg4Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR1101MB2107.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(136003)(39860400002)(366004)(396003)(376002)(346002)(451199015)(38100700002)(82960400001)(33656002)(55016003)(38070700005)(86362001)(316002)(54906003)(6916009)(9686003)(478600001)(71200400001)(26005)(7696005)(6506007)(2906002)(122000001)(83380400001)(8676002)(186003)(64756008)(76116006)(66476007)(66946007)(4326008)(66556008)(41300700001)(5660300002)(66446008)(8936002)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CkgC4s6ODZNf6NE5UeOZcaYlm3ZIHx0Hsrsfa7Fuie4sEwyP1MSCLLjCCpy0?= =?us-ascii?Q?tvkSmsnu0LIcui1OCaQ6AzOrOAfrHYgR5E36FX0hiDQWJ6aZkQTxTss/ubfh?= =?us-ascii?Q?a4my0RgGZ9QmqvaP/tYyeTVBOa2UqaFs8uUnQbWje7tgqwcataiQ9OAXfcQG?= =?us-ascii?Q?8G6AWvFCogX3+cOmaX4YkFtEBb5vdMvdxc5E9ijTulWRPwfNLMnvTXstLQOD?= =?us-ascii?Q?GJfBokrClhDxP26GZAOMzxA43e+VrUOxIgkfu8FJ2L/bplOPs0ahY3igDC+R?= =?us-ascii?Q?NH+wv22AGu+YENGqcaVjNygJbkh77xUMkNyKDlCXVBDzQHRpFI+CsWpVTorW?= =?us-ascii?Q?dDpHzHmOL4LOyLJlmD04hx8QHrfeWXkoziYvafyziW9fupQPVcNOKiAmCjtW?= =?us-ascii?Q?pVVtFkJusm9hnLNxUiNZ0q7TXTwWEdGZD/NLhoSwq53NnJmt+y2hoih68yg8?= =?us-ascii?Q?MVUhYAW3ybnzFNXmPQ/ckeXS6ho+2qZkbz4CU5p3SFtrJTQ4/YLlMDi5QeD0?= =?us-ascii?Q?tUEr3+dijqV2VTF5c0yPvKFVALn3cUnsKInQydBTgn+2ANIUlmv5YNhrVMyA?= =?us-ascii?Q?iQjWZK8vGFiQ5KUcu0MHN1ZCNBsPlIsZZF17/k+pOaFl3K5wHTQ8UCZmsmRP?= =?us-ascii?Q?bV4HJ3d8HkJ54TmjyrFHH2V7i5RPQq87TYc5xFSCzKzw3gm6+lUkUkGMorJe?= =?us-ascii?Q?Oh1khU9sM0t2U4sVCExD4SJAk0apy1v2IXGZVu1Gv8rx9DRjSdN5K0ub4wli?= =?us-ascii?Q?TddKCdI7FPpUNh9p8CWo0coJaIcYEvMLBYVHuwYXuxJFbLw2C+nrNulSV5G5?= =?us-ascii?Q?PBQjYtbF0JucD5MVXjDBV25iLXIyhN4rZIS+V+8oapQvRscD9JnZTUzZ/oeX?= =?us-ascii?Q?ydqFRlndvQJoihLo34mJ2ZRFdsqSFvs3yGAKudWyDfgxV+QmrSn5OFTgZGgK?= =?us-ascii?Q?7EsqqSMNIsGEbqdYDOU6Wd36pRGMSo2AQNSgktTV4YS8anvbPSM99Q2Epxeq?= =?us-ascii?Q?8paUYVuwBjG2Q9Mt9G8ymD7H6yvYV4QNkZjifqHLroHk/j/0Uj5gw/ji/38r?= =?us-ascii?Q?qkFpU8f6EQpBfbwVsEFx6NA8LrZIVCdsX3PXr40me5wkAESBvYxwZ59saAR9?= =?us-ascii?Q?a9EZ0KZspffajkrPM2zSALz+nJoYNII0/wFMSL7pAheee0tX8awokLYXeRMu?= =?us-ascii?Q?O7buxgzM1CpOf4PesWAlE370jxjpyFs4YLnNBQjs+LTYMVwiBmUZ9fCrBMgr?= =?us-ascii?Q?MzcquFT5UCTOlTmtqX5sywiawnnpw+Sg0YkYvcvAzdloxI5rCg/XH1stDRO8?= =?us-ascii?Q?IyC+WGGGijqYdU2ti1hRz9OXwtwhSJ746NR/clPC+NWGdrd1F6a0Koo8rfhA?= =?us-ascii?Q?OkjXcECOG/bCjFNhWyhSYGT1aca4aAJjMmXRJYQvAkosM+nyAIxYkcnb/orC?= =?us-ascii?Q?mvvVMPe0Jn+247hdWb2nZceLSm5QuTgnLvdD10knpzovc/dGgvuTXd6TRO6g?= =?us-ascii?Q?e+XZlO8T1BIzMcLvDkrGMrLXnqqkv7tRA99xfSuvAYaW5J4H3Urdh/ZILqq2?= =?us-ascii?Q?FYjvLUjQ9Qto0lfMi+0FB5Ddi+UeCinhCIc7WmGJ?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR1101MB2107.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ce4394e-aaa7-433f-b8f5-08dad44f124f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2022 10:22:10.0909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 00IfHpmg6TOyxn3/oVycxYprB5RjoMrVbstYbDNd8cnYK9muwrZf4y3bEFf3egKDXbnz62GrwUNAyN+YjCtrwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5540 X-OriginatorOrg: intel.com 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 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 dum= per. > > > > > > > > > > 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 accep= table. > > > > > > @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 patchwo= rk. > > > > "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 dis= played > correctly in the mail. > > > > thread intr thread int= r 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 > > = |<-----------------| > > = | > > __ha= ndle_secondary_request > > eal_dev_hotpl= ug_request_to_secondary > > |<------------------------------------- rte_mp_request_sync > > | > > handle_primary_request--------->| > > | > > __handle_primary_request > > local_dev_remove(this will take long tim= e) > > 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. >=20 >=20 > Part of the problem maybe a hidden file sync in some library. > Normally, closing a file should be fast even with lots of outstanding dat= a. > The actual write done by OS will continue from file cache. >=20 > I wonder if doing some kind of fadvise call might help see > POSIX_FADV_SEQUENTIAL or POSIX_FADV_DONTNEED Thanks for your advice, I will try it and give you feedback.