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 10978A0555; Thu, 26 May 2022 10:36:33 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EF75140E64; Thu, 26 May 2022 10:36:32 +0200 (CEST) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by mails.dpdk.org (Postfix) with ESMTP id 267CE40DF7 for ; Thu, 26 May 2022 10:36:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653554191; x=1685090191; h=message-id:date:subject:to:cc:references:from: in-reply-to:content-transfer-encoding:mime-version; bh=t6lj3R4m07OMHmBrBLBb1u++EtfRvmyhCkhhV1BMswU=; b=ZdHdNknulf68MiGLrJRpZJ+Jjcqirlw3CRLU0c0/SlTR/gQ+CJRfgP/B w/HJM8u9g2lmv2oqOo9wb7JcbXQxz4D+uVYuMuR5Avuncr05GTd/1nuQN B2KfH9Eu8NQ0LQGHcQVrWb3vRIp545N8NfexcvZlaYt5RmdgmfKsaBp9a RfXbE7eMSa7YhsQWUTh0VpnUb/NjD5r4rX8mUN+rgE8jihnCLhXQkzqUP +bCqECVidP4xWT3fpD+qyN8j+CtJW7c3YKm0MP6xqULwWSyWFmF7bNxtU ASC2Ry61hq4BrA0yjMcqjr0C0egyT73QSRCTFfx5xStSX1raJOGtI+7zY g==; X-IronPort-AV: E=McAfee;i="6400,9594,10358"; a="253958878" X-IronPort-AV: E=Sophos;i="5.91,252,1647327600"; d="scan'208";a="253958878" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 May 2022 01:36:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,252,1647327600"; d="scan'208";a="704419674" Received: from fmsmsx606.amr.corp.intel.com ([10.18.126.86]) by orsmga004.jf.intel.com with ESMTP; 26 May 2022 01:36:29 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx606.amr.corp.intel.com (10.18.126.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27; Thu, 26 May 2022 01:36:29 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.27 via Frontend Transport; Thu, 26 May 2022 01:36:28 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.47) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.27; Thu, 26 May 2022 01:36:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VdmEIvHHPric7k8XL09n6rCiZUlbeqQBkyvHia4NGDZeHw9w9RLSVi83qodbnUtdjnsXcembSKuFsEdgXxzuUF/DUps1d+7W/eiEnxGdbN3o5ZWOrfXt3KO9p+ocmbcFnYhX3AT0mLyFKkcEcnAMKswVUpdTKXMEGJ3enP9PSTiVXsf3vgtj5Skcw7DTwmfvi4rkKnnfvgGQpHlxHsVT8NOaJGv6Z1nW8EY0HBT7LhGIpcdViIPRxe16FIbOTAwOfP3STSIlZZVBaHtv0hZZnYGYr4rCej5VpLGOphbRexyE2iizK6fenklQ7k7DPUk6uESMEZTQ5tiGkyIAvdy1UQ== 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=yF9BQmMYMJhErIep9Hx5869gmmG4xcykd7HC1VZGlr0=; b=bCAt37FNXZRDQTSaQvA7bKIDepZBuK4vMZM7Hxxg9NF/COPQRH0cLnD2GuQsyZ06tPFBZ1WJniV1Uipfrt3PlcUiAmFwtgrA98ZiEiFF7MiyOSrEapY5a7eYI40rIpaceRJ31iAUICtVQmyp4gPCqVL2tx8NEKcbvjTcNQBJ4dpH++PFFnEhLnutVg+d8HtYzCycPC04I926wjkXJw81kPmkIIyWjR+OOZ5gj48AaeExXNwSGaSLY6G0lhWvpZ6HbCa5TqgTvpS46/zueFQeaZ86X4u85YFv8WDlGfpIf27apM1YKZkNRnFf4GKsQFBXB7Chfs3lfE2LchhmoH9GjQ== 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 Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) by DM5PR11MB1449.namprd11.prod.outlook.com (2603:10b6:4:8::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5273.17; Thu, 26 May 2022 08:36:26 +0000 Received: from MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::d55d:28c1:bfab:3dd]) by MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::d55d:28c1:bfab:3dd%5]) with mapi id 15.20.5273.023; Thu, 26 May 2022 08:36:26 +0000 Message-ID: <633738e1-9da7-3613-f513-af4cfa4348b0@intel.com> Date: Thu, 26 May 2022 09:36:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH v5] eal: add bus cleanup to eal cleanup To: Bruce Richardson CC: , =?UTF-8?Q?Morten_Br=c3=b8rup?= References: <20220419161438.1837860-1-kevin.laatz@intel.com> <20220525103953.543447-1-kevin.laatz@intel.com> From: Kevin Laatz In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0059.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::23) To MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a077f1b8-59b9-4a9b-f486-08da3ef2d24b X-MS-TrafficTypeDiagnostic: DM5PR11MB1449:EE_ X-LD-Processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HGKkmBNrpFO2ZKRpqAVZ4j4BMZuaE3ogbk09vTkSRi/RgojAcspB8Uty9ZdBp+wGLyKZG7WLZXeN1IjbBHoND1lJizHaMOZW/UEW4QF4cN5eePpDZBOiPUil24xifBr44CQnyXQqUvKQh779nelAjY58VD0froBL8YlNDWH7HDW6NuBfTEtgU8hVXrv7bht5fiWR6w9EQV3Dn8x7lSFelbL++cO51m+WglUIwm0BfIbyMoAaSBPbBVJds0Q2eniBa23A5kLmfxl9YRP1h+TUNrjybVntp7JykGs4fQfen3tpdbDwmzL+CHvN7YvfAaw0vhMa8zAJhV281TfzWyU50g0fIFrr5s2x/+/RGLMLhhclkOwTHmXTxbOdq6XluRK2NjPdSCSFBpptlmjdlRTjRZSAl1UBgs3/loDru1NjfqjPbMK2XLuiVpNVdvIY1AZPteKwiHgM0iWt082960Uy8MSRsAtBn7TuWDQj3KZp6NUyRtxK6MAbIvoSXgPl3Sp8HPY0ONApT8sq8vwLigQ10KP5/eX/pIL9JOb/7meLK8YCZglxKZ5LL5wr4bUKkQuBAehdk0HPla2aH8Zx5ISBwC846rdoJEVZLnnVFnYWjHwZ4Fm7YhElxcDp8vjm8FCv+UbCnj93FDyyKzJ+nR8HbZvq4YC11QRGhoFkVQbxC17fDnbs2XIjLryQfru08gtwyqtZe07OwThDx2kEKuKeTlClsRVXaZkl5ExUiMz2CUY= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW4PR11MB5872.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(82960400001)(36756003)(44832011)(6506007)(316002)(53546011)(31686004)(6666004)(6512007)(66946007)(66476007)(66556008)(26005)(83380400001)(5660300002)(2906002)(4326008)(6862004)(8676002)(508600001)(37006003)(6636002)(6486002)(31696002)(186003)(66574015)(2616005)(86362001)(38100700002)(8936002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TUJkbHRPYVc5ZVlOcFhVeXVSVlJPcE5VZDB6VWltdm12RHBLTUpxWGh3SWR2?= =?utf-8?B?QzV4ejNCUDZMeG1Fc2NZSytZMjVzTVdEUFY2OVoyaVY2Nk85dlVoclF5cUVv?= =?utf-8?B?cXBWZExDMlF6V2FrcU16ZGs4K3grcjEyMFhSZkFXUEJEUzFhclY2UjRKN2Q3?= =?utf-8?B?T2lIaTYxL2taME9IOWhFQ0s3eVhRMFNVMEoyelMrY24xYVo3QW5GR0JhbEFu?= =?utf-8?B?TmdWZDRscVJyK2hHUE93WElzaSt5MHowZEdWcGNKdGFrS3dsZDRFWVhFdUM0?= =?utf-8?B?WFdTOEpIcHdNcDlEQmY4bWM2cjNHWFg5U283SFFMTVBOK0dSMmZZZXpvQU92?= =?utf-8?B?aDBDYWZnZ0pwTEZxdnpURDJ0WUUwZ2ZnZzZHR0pJTk00M2xWSjF3Z1hGcGpn?= =?utf-8?B?c1g2NzJrdFE3UlRRTGpFdlBsNUswUVp1bit6RXVBR3pMSkZQOG1rYTdhZ3BR?= =?utf-8?B?aHRDQUduQkgzZHliTTlkSHc0eHFNZUllU3MrcWVQdDM2NlJ6WUQwUWRFV0p5?= =?utf-8?B?MDgzMlo5eHBYVGgvR0VTTlMwYy91blZwK0ZkeWkwSlEvMEp2ZGJMR2YwS1Ex?= =?utf-8?B?V25valVmNGtnZndBVWFTNUtleEdnbmNvQVdVbzFmUFk1cEFXN2NlMXhNRGZE?= =?utf-8?B?Z2xwSzh6QU4yd1d4VGJoZ0Rmc0VReUVFeGs3SlJLOXB0anIyeTdpNFlpbVd5?= =?utf-8?B?a295M3dxTWN6azErcG1YL1Y0U2xMSlBQNjNEb21WZ2JpQ0dlQzJUVUYzSUVx?= =?utf-8?B?RDlJUVJoVkYzM1IrLzUzNEFYRXQ0cWVBMEgwalhVTFltUUNwRnpvWlcyMUpP?= =?utf-8?B?UDM4U1hZYk0xVGtOR09lcWtSTkFNbzVKaVlIQnJML2ZkWkR5eEVZdFB2UFFq?= =?utf-8?B?eGdaSXpTSEd2THF5Uk1NRVF6NzhsNGd0eVZkcmw5L2pUdGdQcEJjYkQvc2R1?= =?utf-8?B?bzZaSzk1MTd4SEg2VjNacjBDMFV4SGFUK2lFa2dTTEZlWDRFclEwU21rdWxL?= =?utf-8?B?NHhTYmpCQ0haTld5MnNxUGZHTEdkdHBLS3JpZSszdnhVNTZpdVRHQlZGRWlP?= =?utf-8?B?NWw5dG9iNUZpUldWVXhpbndZa2paYkV4cTVRRm02bGtxQ3VVbU1aNDVwSm1q?= =?utf-8?B?RGl1U0Zuc0s0dzEvQlZrUlpKZW5pU25Xd01FWEVQSTI2bmRiVDE4NWpJVXB2?= =?utf-8?B?TVg2cEtVemMzQ2dVbEFsQ2x6WFZDMmNDTTNZdUVUZ05kTC80dWg1RVU2NEdp?= =?utf-8?B?NUo5WFp5ckhNNHZRSi9BcjNFajM3TFBkeXpjZjllQ1lPU1hNSk03RFZJYkNU?= =?utf-8?B?R1Y0K0pNVk9jc0RIVXNySVh3bVArclRTY2RVYVlRbG1GbEtLK1h0Yi9Mak5o?= =?utf-8?B?QzhMaVI2ZkdSb2tORGYrZWNIK2lZMGxjK3NBUlJoWWFZYllCWWNUVnN3dkpF?= =?utf-8?B?Sk9MdDdvbGllRm9saThYYjhjVURsR0RjRkZ1RVFWRnNhSlVMNXNSYWd4dXhY?= =?utf-8?B?Tk5GUGYyWi9DZkRxY3d1RWRMTnl1SHA4aEcwZGkwQmt6bVE1REN6emhJMVVF?= =?utf-8?B?a1Fzb2lMVHRESTRydFFtQVdRQ3JiZmh2Y3ZDVE9oWW54d0xMbWFiQ0czR25i?= =?utf-8?B?eUdkSzkvWkcxaU5rbGcvYzFDTlU3VzZxRHUrRzdVUzNxYlRhVWliMXB0MGVK?= =?utf-8?B?d242R3VNbUxGQWRldG1oYVZUSDByL3JyV2o1djVJUC9ZRUw3L3lqbnhmN1p5?= =?utf-8?B?Q21QYW1WcnU0V3l4SmdqRUlLaEdaZE14c3RSenIwc0p6RUZ4NmJVZVh6bkdC?= =?utf-8?B?cXBNQTRmVzNZdHFCNVJ6bnQ3d2Q1aC9IUkxnaTI0bGxEcUZ3eTBZWlkwTDZE?= =?utf-8?B?TnJVaGcyOWNlOGVML3V4cnRDdEpydUNZQ21KWkVEZVNaczZkYlJZT3JjTmh5?= =?utf-8?B?VG5OS2hjN2c5NnRDcHVWVjdzdU82MVBEbWM1QXFZaGFXSlFPRjNUZWhvV0Jh?= =?utf-8?B?SlhiUHh6Q21xQzE1eWxVOG5tU3JYWFYxczc4YkNiNmpFWmtKdlQ4a1lHTnNI?= =?utf-8?B?S05XYWQzaGJUN1g5TVU5bWVzeDBGbmRtRUpKbStjZGI4bVd6ZDR6UHhrcWN6?= =?utf-8?B?KzMwK3lJdmxtdlRoaHU4bHUvVDB4NDBUaHJnWG5uWDZIU0ZBT1pBZ3FRZzVZ?= =?utf-8?B?OUZRSE5Cb3JWb2MyT2hiNFRqUWdYZWQ3YzFYbHBDc1NiWDlQZGFKRi9LN0h0?= =?utf-8?B?QVZNNlZKdHpwNTQrUXU4WitYR0dDM21XRmp2QXhYK3ZvVm9ud3g4VExQWHVV?= =?utf-8?B?SDVCU1NhQnE3SkMrQmp5UjEzRlZ3eFFOUmk2ODdVaUh1ZUYvMmlmVWY4ZHR1?= =?utf-8?Q?B5cv3BdrDA/IpjMg=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: a077f1b8-59b9-4a9b-f486-08da3ef2d24b X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB5872.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 May 2022 08:36:26.0515 (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: jwodfzHHJVDcHGXibYwBLEIWGghaUH68ky/7Z4WvUjxgA2g2Q2jGLNB1AHOQvYpBpdCBRtRQnL3BMTDzkJJzaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1449 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 25/05/2022 12:12, Bruce Richardson wrote: > On Wed, May 25, 2022 at 11:39:53AM +0100, Kevin Laatz wrote: >> During EAL init, all buses are probed and the devices found are >> initialized. On eal_cleanup(), the inverse does not happen, meaning any >> allocated memory and other configuration will not be cleaned up >> appropriately on exit. >> >> Currently, in order for device cleanup to take place, applications must >> call the driver-relevant functions to ensure proper cleanup is done before >> the application exits. Since initialization occurs for all devices on the >> bus, not just the devices used by an application, it requires a) >> application awareness of all bus devices that could have been probed on the >> system, and b) code duplication across applications to ensure cleanup is >> performed. An example of this is rte_eth_dev_close() which is commonly used >> across the example applications. >> >> This patch proposes adding bus cleanup to the eal_cleanup() to make EAL's >> init/exit more symmetrical, ensuring all bus devices are cleaned up >> appropriately without the application needing to be aware of all bus types >> that may have been probed during initialization. >> >> Contained in this patch are the changes required to perform cleanup for >> devices on the PCI bus and VDEV bus during eal_cleanup(). There would be an >> ask for bus maintainers to add the relevant cleanup for their buses since >> they have the domain expertise. >> >> Signed-off-by: Kevin Laatz >> Acked-by: Morten Brørup >> >> --- >> v5: >> * remove unnecessary logs >> * move rte_bus_cleanup() definition to eal_private.h >> * fix return values for vdev_cleanup and pci_cleanup >> > Hi Kevin, > > few more comments inline below. > > Also, with this change, does it mean that we can remove the cleanup done at > the end of testpmd and some other apps? If so, perhaps that should be done > in a separate patch to make this a multi-patch series. With these changes there will be some overlapping cleanup. I'll look into removing any dupliation, however depending on the app there may be other cleanup that still needs to stay in place. > /Bruce > >> v4: >> * rebase >> >> v3: >> * add vdev bus cleanup >> >> v2: >> * change log level from INFO to DEBUG for PCI cleanup >> * add abignore entries for rte_bus related false positives >> --- >> devtools/libabigail.abignore | 9 +++++++++ >> drivers/bus/pci/pci_common.c | 24 ++++++++++++++++++++++++ >> drivers/bus/vdev/vdev.c | 24 ++++++++++++++++++++++++ >> lib/eal/common/eal_common_bus.c | 17 +++++++++++++++++ >> lib/eal/common/eal_private.h | 10 ++++++++++ >> lib/eal/include/rte_bus.h | 13 +++++++++++++ >> lib/eal/linux/eal.c | 1 + >> 7 files changed, 98 insertions(+) >> >> diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore >> index 79ff15dc4e..3e519ee42a 100644 >> --- a/devtools/libabigail.abignore >> +++ b/devtools/libabigail.abignore >> @@ -56,3 +56,12 @@ >> ; Ignore libabigail false-positive in clang builds, after moving code. >> [suppress_function] >> name = rte_eal_remote_launch >> + >> +; Ignore field inserted to rte_bus, adding cleanup function >> +[suppress_type] >> + name = rte_bus >> + has_data_member_inserted_at = end >> + >> +; Ignore changes to internally used structs containing rte_bus >> +[suppress_type] >> + name = rte_pci_bus, rte_vmbus_bus, rte_vdev_bus >> diff --git a/drivers/bus/pci/pci_common.c b/drivers/bus/pci/pci_common.c >> index 37ab879779..5dd486019f 100644 >> --- a/drivers/bus/pci/pci_common.c >> +++ b/drivers/bus/pci/pci_common.c >> @@ -394,6 +394,29 @@ pci_probe(void) >> return (probed && probed == failed) ? -1 : 0; >> } >> >> +static int >> +pci_cleanup(void) >> +{ >> + struct rte_pci_device *dev = NULL; >> + int error = 0; >> + >> + FOREACH_DEVICE_ON_PCIBUS(dev) { >> + struct rte_pci_driver *drv = dev->driver; >> + int ret = 0; >> + >> + if (drv == NULL) >> + continue; >> + >> + ret = drv->remove(dev); >> + if (ret < 0) { >> + rte_errno = errno; >> + error = -1; >> + } >> + } >> + >> + return error; >> +} >> + >> /* dump one device */ >> static int >> pci_dump_one_device(FILE *f, struct rte_pci_device *dev) >> @@ -813,6 +836,7 @@ struct rte_pci_bus rte_pci_bus = { >> .bus = { >> .scan = rte_pci_scan, >> .probe = pci_probe, >> + .cleanup = pci_cleanup, >> .find_device = pci_find_device, >> .plug = pci_plug, >> .unplug = pci_unplug, >> diff --git a/drivers/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c >> index a8d8b2327e..78d6e75b89 100644 >> --- a/drivers/bus/vdev/vdev.c >> +++ b/drivers/bus/vdev/vdev.c >> @@ -569,6 +569,29 @@ vdev_probe(void) >> return ret; >> } >> >> +static int >> +vdev_cleanup(void) >> +{ >> + struct rte_vdev_device *dev; >> + int error = 0; >> + >> + TAILQ_FOREACH(dev, &vdev_device_list, next) { >> + const char *name; >> + struct rte_vdev_driver *drv; >> + int ret = 0; >> + >> + name = rte_vdev_device_name(dev); >> + if (vdev_parse(name, &drv)) >> + continue; >> + > The vdev_device struct contains an rte_device struct which contains a > pointer to the driver. Can that not be used rather than calling vdev_parse? Ack > >> + ret = drv->remove(dev); >> + if (ret < 0) >> + error = -1; >> + } >> + >> + return error; >> +} >> + >> struct rte_device * >> rte_vdev_find_device(const struct rte_device *start, rte_dev_cmp_t cmp, >> const void *data) >> @@ -627,6 +650,7 @@ vdev_get_iommu_class(void) >> static struct rte_bus rte_vdev_bus = { >> .scan = vdev_scan, >> .probe = vdev_probe, >> + .cleanup = vdev_cleanup, >> .find_device = rte_vdev_find_device, >> .plug = vdev_plug, >> .unplug = vdev_unplug, >> diff --git a/lib/eal/common/eal_common_bus.c b/lib/eal/common/eal_common_bus.c >> index baa5b532af..be62776a2d 100644 >> --- a/lib/eal/common/eal_common_bus.c >> +++ b/lib/eal/common/eal_common_bus.c >> @@ -85,6 +85,23 @@ rte_bus_probe(void) >> return 0; >> } >> >> +/* Clean up all devices of all buses */ >> +int >> +rte_bus_cleanup(void) >> +{ >> + int ret = 0; >> + struct rte_bus *bus; >> + >> + TAILQ_FOREACH(bus, &rte_bus_list, next) { >> + if (bus->cleanup == NULL) >> + continue; >> + if (bus->cleanup()) >> + ret = -1; > Make comparison explicit, I think, i.e. add "!= 0" or "< 0" in if > statement. Ack > >> + } >> + >> + return ret; >> +} >> + >> /* Dump information of a single bus */ >> static int >> bus_dump_one(FILE *f, struct rte_bus *bus) >> diff --git a/lib/eal/common/eal_private.h b/lib/eal/common/eal_private.h >> index 44d14241f0..df190702a3 100644 >> --- a/lib/eal/common/eal_private.h >> +++ b/lib/eal/common/eal_private.h >> @@ -441,6 +441,16 @@ int rte_eal_memory_detach(void); >> */ >> struct rte_bus *rte_bus_find_by_device_name(const char *str); >> >> +/** >> + * For each device on the buses, perform a driver 'match' and call the >> + * driver-specific function for device cleanup. >> + * >> + * @return >> + * 0 for successful match/cleanup >> + * !0 otherwise >> + */ >> +int rte_bus_cleanup(void); >> + > Since this is now a private function, remove the rte_ prefix. Suggest > "eal_bus_cleanup" as a function name. Yes, makes sense > >> /** >> * Create the unix channel for primary/secondary communication. >> * >> diff --git a/lib/eal/include/rte_bus.h b/lib/eal/include/rte_bus.h >> index bbbb6efd28..9908a013f6 100644 >> --- a/lib/eal/include/rte_bus.h >> +++ b/lib/eal/include/rte_bus.h >> @@ -66,6 +66,18 @@ typedef int (*rte_bus_scan_t)(void); >> */ >> typedef int (*rte_bus_probe_t)(void); >> >> +/** >> + * Implementation specific cleanup function which is responsible for cleaning up >> + * devices on that bus with applicable drivers. >> + * >> + * This is called while iterating over each registered bus. >> + * >> + * @return >> + * 0 for successful cleanup >> + * !0 for any error during cleanup >> + */ >> +typedef int (*rte_bus_cleanup_t)(void); >> + >> /** >> * Device iterator to find a device on a bus. >> * >> @@ -277,6 +289,7 @@ struct rte_bus { >> /**< handle hot-unplug failure on the bus */ >> rte_bus_sigbus_handler_t sigbus_handler; >> /**< handle sigbus error on the bus */ >> + rte_bus_cleanup_t cleanup; /**< Cleanup devices on bus */ >> >> }; >> >> diff --git a/lib/eal/linux/eal.c b/lib/eal/linux/eal.c >> index 1ef263434a..27014fdc27 100644 >> --- a/lib/eal/linux/eal.c >> +++ b/lib/eal/linux/eal.c >> @@ -1266,6 +1266,7 @@ rte_eal_cleanup(void) >> vfio_mp_sync_cleanup(); >> #endif >> rte_mp_channel_cleanup(); >> + rte_bus_cleanup(); >> /* after this point, any DPDK pointers will become dangling */ >> rte_eal_memory_detach(); >> eal_mp_dev_hotplug_cleanup(); > Is this change not also applicable for FreeBSD and windows? Will add this to both, thanks.