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 73E6FA0C54; Mon, 23 Aug 2021 06:14:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 41E9E40143; Mon, 23 Aug 2021 06:14:33 +0200 (CEST) Received: from CNSHJSMIN03.NOKIA-SBELL.COM (cnshjsmin03.nokia-sbell.com [116.246.26.71]) by mails.dpdk.org (Postfix) with ESMTP id 7EFE44003E for ; Mon, 23 Aug 2021 06:14:31 +0200 (CEST) X-AuditID: ac189297-dd7ff700000025fe-89-612320a481d0 Received: from CNSHPPEXCH1610.nsn-intra.net (Unknown_Domain [135.251.51.110]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by CNSHJSMIN03.NOKIA-SBELL.COM (Symantec Messaging Gateway) with SMTP id A1.49.09726.4A023216; Mon, 23 Aug 2021 12:14:28 +0800 (HKT) Received: from CNSHPPEXCH1601.nsn-intra.net (135.251.51.101) by CNSHPPEXCH1610.nsn-intra.net (135.251.51.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 23 Aug 2021 12:14:28 +0800 Received: from CNSHPPEXCH1601.nsn-intra.net ([135.251.51.101]) by CNSHPPEXCH1601.nsn-intra.net ([135.251.51.101]) with mapi id 15.01.2176.012; Mon, 23 Aug 2021 12:14:28 +0800 From: "Yan, Xiaoping (NSB - CN/Hangzhou)" To: "dev@dpdk.org" Thread-Topic: remove dpdk-pdump pcap file, disk space is not freed Thread-Index: AdeX0u/Cqg0If1mwS7O1fJo+nqnskA== Date: Mon, 23 Aug 2021 04:14:28 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.251.51.115] MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsXS/ts4T3eJgnKiwYwpuhbvPm1ncmD0+LVg KWsAYxSXTUpqTmZZapG+XQJXxu3HGQW7AiomT97O1MB4wLWLkZNDQsBEYtLSVqYuRi4OIYFD TBIvv99gAUkICfxllLh6XhsisQnIvnuXCSTBJuAh8eLEVmYQW0RAUWL6xMlsILawgK3EhY8N bBBxJ4nbl2exdzFyANl6EueXVIOYLAKqEms61UAqeAXsJGb8Owg2hVFAVmLao/tg05kFxCVu PZnPBHGbgMSSPeeZIWxRiZeP/7GCjJEQUJLo2wBVnirRfmABO8RIQYmTM5+wTGAUmoVk0iwk ZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjNLOfsEeXsG+nn4Gxnp+/t6ejrrB Tq4+PnrO/r6bGIGRsUZi0vQdjOfmftM7xMjEwXiIUYKDWUmE9y+TcqIQb0piZVVqUX58UWlO avEhRmkOFiVx3kMFwolCAumJJanZqakFqUUwWSYOTqkGpkkKCUq/WhXXh+ywdnN42MxyPMpk 0ofrfse3r3A8vejg4Z/y+cF6CZuuFzdytj30uKX6xZbv+ld9G96uojl/Q4yEA1b1Lj+a+8V+ h9Tyfe/rYnq+/ZLq1201CHjGrXCgr0ZQvo1vx7YEh5+VR64mHTOdrVZkNvOf/kP2hU/Nf4Sq fmDz3eXKtJqvZdb9Wr9Zwd8yDveKCKy7/uNm/J45RwM+fY/itDvDf/BrX1boF5Pm8ODaqbOn Pl2g5ZpxrGO3w4u3d1INF74Kk1k3ad2/Nwd9ZGr4pry/U76+lUvilO6qq7klruL3rI46TFWf qtRzsNfSInuu6bMby/5slJf9Hu+y5GjXw0ciiibpzZnbzyuxFGckGmoxFxUnAgBFWw1T+wIA AA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 Subject: [dpdk-dev] remove dpdk-pdump pcap file, disk space is not freed 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 Sender: "dev" Hi, Before I run pdump, 21MB is used in /tmp tmpfs 63G 21M 63G 1% /tmp Then I run pdump with such command: dpdk-pdump -c 0x4001000400100 -a 0000:03:00.6 -a 0000:03:06.1 --legacy-mem= --base-virtaddr 0x2aaa2aa000 --file-prefix l2rt -- --pdump port=3D1,queue= =3D*,rx-dev=3D/tmp/l2biprt.pcap,tx-dev=3D/tmp/l2biprt.pcap,mbuf-size=3D1024= 0,total-num-mbufs=3D10000 After stop, it generates a 14MB file -rw-rw-r--. 1 9999 9999 14M Aug 23 03:58 l2biprt.pcap And 35M is used in /tmp tmpfs 63G 35M 63G 1% /tmp And fuser show there are still several users of this file. (all these pids = are of running dpdk primary and secondary processes ) # fuser /tmp/l2biprt.pcap /tmp/l2biprt.pcap: 139 342 347 434 Then after I rm the file (l2biprt.pcap), disk space in tmp is not freed (st= ill 35MB used) rm l2biprt.pcap df -h tmpfs 63G 35M 63G 1% /tmp It seems it goes like this: pdump start->pdump send vdev hotplug add request->primary and = secondary process calls pmd_pcap_probe() which opens the pcap file-> pdump stop-> pdump send vdev hotplug remove request-> primary= and secondary process does not close the pcap file To properly close the pcap file and release disk space, it seems we should: * somehow close the pcap file in "vdev hotplug remove", or * don't open the pcap file in "vdev hotplug add"( pmd_pcap_probe()), it= seems pcap eth_dev_start will open the pcap file in case it was not opened= . Any comment is appreciated, thank you. Best regards Yan Xiaoping