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 84302A054D; Tue, 7 Jun 2022 17:12:19 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E65D4021D; Tue, 7 Jun 2022 17:12:19 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mails.dpdk.org (Postfix) with ESMTP id A6A4A40156 for ; Tue, 7 Jun 2022 17:12:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654614737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=q4sMNLHLTHH5D0m+TnZHmGynemYRfrGUiREA9SnQGXE=; b=KNSnq+1jmNOqlRnODEVaMBLKTQLpr0jmNADO54AWViFasyrYrcbK9qRF3k6f1H9UkgOQNW +nnXue0+FLJb+nvniEL8oYdjF7IsMnx2+gHt1YCOLUcq9inSaQPEin1TFXQ6GUzL4fq4Fm GEgxOmyKHa00SazOi35lHsQr0sQgvzM= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-36-2jXxDJ7JOraglwDQzQQyjA-1; Tue, 07 Jun 2022 11:12:16 -0400 X-MC-Unique: 2jXxDJ7JOraglwDQzQQyjA-1 Received: by mail-lf1-f72.google.com with SMTP id i26-20020a0565123e1a00b004792c615104so3873592lfv.12 for ; Tue, 07 Jun 2022 08:12:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q4sMNLHLTHH5D0m+TnZHmGynemYRfrGUiREA9SnQGXE=; b=CZlDTOdZvBzYaPXwu1Z+Qv6VAS3eSuvI7rkGO4EKc06AnRyf/CwqEShxuyIhtRFs8h GDhNBAncCWMwFQRpH45qur3T9SCwCevnapt2+9nYgNg0k/V3KlbXqwkYjXo1ap94iBZH f6zEaw+sB/6fP8livCpVlIOAko4cuu1LV+sf2ahwJffrJW60Numd25ccKr6oOKBuhxWm wFC6roAfQv7ljYLdM8xXv43ZoVH2LxgPqlEDZVgeKWvWfZMr8rpnSTP4HZ6dbUagHx0M m73IeTyFOoNxspN3L6e2wQUB1hKOR2XKSSKhRcWqcYDK2yFR9ks/8QEFhmR4HyhBSy3J 20MQ== X-Gm-Message-State: AOAM531ko8KepRWYzGlP9yEKdch3c1KKBeSRGofFKBrRmQ5eHQRXk9rg c6PPfGUHIm1iMPRR2lIz4U0eYRfFj8EtPDBykijWLNgUYfZznp9FOW4Nt0QiDatfJNONI/DZqNx nPbEN0QuAUZLw7oE1jKs= X-Received: by 2002:ac2:4c15:0:b0:479:cb6:f8da with SMTP id t21-20020ac24c15000000b004790cb6f8damr18685769lfq.484.1654614734225; Tue, 07 Jun 2022 08:12:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwYjepcQWb3IoI2UAB+ofqk3FAr517iBGEHBHeTBQPxr8ydO3tCGV+1o32mpo/tAYDRCLZwvwENAzSyl6BuXJ0= X-Received: by 2002:ac2:4c15:0:b0:479:cb6:f8da with SMTP id t21-20020ac24c15000000b004790cb6f8damr18685753lfq.484.1654614733955; Tue, 07 Jun 2022 08:12:13 -0700 (PDT) MIME-Version: 1.0 References: <20220419161438.1837860-1-kevin.laatz@intel.com> <20220603143601.230519-1-kevin.laatz@intel.com> <7465552.R56niFO833@thomas> In-Reply-To: <7465552.R56niFO833@thomas> From: David Marchand Date: Tue, 7 Jun 2022 17:12:02 +0200 Message-ID: Subject: Re: [PATCH v7] eal: add bus cleanup to eal cleanup To: Thomas Monjalon , Kevin Laatz Cc: dev , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Bruce Richardson , Li Zhang , Matan Azrad , Stephen Hemminger , lihuisong Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" 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, Jun 7, 2022 at 1:09 PM Thomas Monjalon wrote: > > 03/06/2022 16:36, Kevin Laatz: > > 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. > [...] > > --- 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 (This change is strange as there is no rte_vdev_bus type, but I won't investigate the relevance of this rule for now). > > I'm not sure we can safely consider these structs as internal. > The right process is to send a deprecation notice, > and then remove them from the public API. Same for me, I don't think we can safely ignore. A rte_bus struct is embedded in rte_pci_bus (resp. rte_vmbus_bus). If we make it grow, any inlined access (like walk in device_list or driver_list) after the rte_bus object is broken for code accessing it out of DPDK. Such code might exist out there, since we expose FOREACH_DEVICE_ON_PCIBUS, for example. > > For info, Li has sent a patch for the bus cleanup > which is not updating the bus code: > https://patches.dpdk.org/project/dpdk/patch/20220606114650.209612-3-lizh@nvidia.com/ > It may be a temporary solution before the deprecation. On the principle, that's probably the best, there is no question about unclear frontier of the ABI. (In practice though, the mentionned patch is triggering segfaults in two CI, for pdump). Hiding rte_bus object should be straightforward in v22.11, I had some patches, but never finished the work. It would be great too, to look into rte_driver and rte_device which are exposed important types, but that's another story. -- David Marchand