DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: Thomas Monjalon <thomas@monjalon.net>,
	Kevin Laatz <kevin.laatz@intel.com>
Cc: dev <dev@dpdk.org>, "Morten Brørup" <mb@smartsharesystems.com>,
	"Bruce Richardson" <bruce.richardson@intel.com>,
	"Li Zhang" <lizh@nvidia.com>, "Matan Azrad" <matan@nvidia.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	lihuisong <lihuisong@huawei.com>
Subject: Re: [PATCH v7] eal: add bus cleanup to eal cleanup
Date: Tue, 7 Jun 2022 17:12:02 +0200	[thread overview]
Message-ID: <CAJFAV8yB5f6AHoOuY=OELS062LVD=T3ksrj6vmHGcKyZciO7bg@mail.gmail.com> (raw)
In-Reply-To: <7465552.R56niFO833@thomas>

On Tue, Jun 7, 2022 at 1:09 PM Thomas Monjalon <thomas@monjalon.net> 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


  reply	other threads:[~2022-06-07 15:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-19 16:14 [RFC] " Kevin Laatz
2022-04-19 16:36 ` Stephen Hemminger
2022-04-20  6:55 ` Morten Brørup
2022-04-22  9:18   ` Kevin Laatz
2022-04-22 12:14     ` Morten Brørup
2022-04-22 16:27 ` [RFC v2] " Kevin Laatz
2022-05-24  9:08 ` [PATCH v3] " Kevin Laatz
2022-05-24  9:25 ` [PATCH v4] " Kevin Laatz
2022-05-24  9:38   ` Bruce Richardson
2022-05-24 15:19     ` Kevin Laatz
2022-05-24 14:48   ` Stephen Hemminger
2022-05-24 15:20     ` Kevin Laatz
2022-05-25 10:39 ` [PATCH v5] " Kevin Laatz
2022-05-25 11:12   ` Bruce Richardson
2022-05-26  8:36     ` Kevin Laatz
2022-06-01 17:02 ` [PATCH v6] " Kevin Laatz
2022-06-01 17:03   ` Bruce Richardson
2022-06-02  2:06   ` lihuisong (C)
2022-06-03 14:35     ` Kevin Laatz
2022-06-03 14:36 ` [PATCH v7] " Kevin Laatz
2022-06-03 15:11   ` Stephen Hemminger
2022-06-03 15:39     ` Bruce Richardson
2022-06-04  2:07   ` lihuisong (C)
2022-06-07 11:09   ` Thomas Monjalon
2022-06-07 15:12     ` David Marchand [this message]
2022-06-13 15:58       ` Bruce Richardson
2022-10-03 12:35         ` David Marchand
2022-10-03 14:39           ` Kevin Laatz
2022-10-04 13:11 ` [PATCH v8] " Kevin Laatz
2022-10-04 15:28   ` David Marchand
2022-10-04 15:36     ` Kevin Laatz
2022-10-04 16:50 ` [PATCH v9] " Kevin Laatz
2022-10-05  7:45   ` David Marchand
2022-10-05  9:41     ` Thomas Monjalon
2022-10-05 11:03       ` Kevin Laatz
2022-10-05 12:06         ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJFAV8yB5f6AHoOuY=OELS062LVD=T3ksrj6vmHGcKyZciO7bg@mail.gmail.com' \
    --to=david.marchand@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=kevin.laatz@intel.com \
    --cc=lihuisong@huawei.com \
    --cc=lizh@nvidia.com \
    --cc=matan@nvidia.com \
    --cc=mb@smartsharesystems.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).