From: Thomas Monjalon <thomas@monjalon.net>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>
Cc: "Varghese, Vipin" <vipin.varghese@intel.com>,
"stable@dpdk.org" <stable@dpdk.org>,
"dev@dpdk.org" <dev@dpdk.org>,
bruce.richardson@intel.com, konstantin.ananyev@intel.com,
olivier.matz@6wind.com
Subject: Re: [dpdk-stable] [PATCH v2] app/procinfo: Fix memory leak by rte_service_init
Date: Fri, 26 Jan 2018 18:26:54 +0100 [thread overview]
Message-ID: <27105962.SPFB230vh8@xps> (raw)
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA651006FDA@IRSMSX102.ger.corp.intel.com>
26/01/2018 18:15, Van Haaren, Harry:
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > 11/01/2018 20:47, Vipin Varghese:
> > > When procinfo is run multiple times against primary application, it
> > > consumes huge page memory by rte_service_init. Which is not released
> > > at exit of application.
> > >
> > > Invoking rte_service_finalize to real memory and prevent memory leak.
> >
> > I don't think it is correct to call rte_service_finalize in applications,
> > while rte_service_init is called in EAL.
> >
> > Maybe we need a new function in EAL.
>
> Yes correct - we need a rte_eal_deinit(), cleanup() or finalize() or something. This ties in with splitting EAL to be more modular on startup, and DPDK in general behaving more like a library and less like a single-monolith.
>
> For the 18.02 timeframe, the simplest solution to solve the secondary process mem-leak issue than to merge into these applications, unfortunately.
>
> The only other option I see is to add an rte_eal_finalize() function, and hide this call behind it, however it is quite late to add such a function, and what do we do with cases like rte_panic(), rte_exit(), or system signals like SIGINT, SIGHUP etc? It seems too complicated to add "quickly" to me.
>
> If there is technically a better solution viable in the given timeframe, I'm open to suggestions?
I think it is better to keep the leak in 18.02,
and takes time to fix it properly in 18.05.
If you really think it is a major bug, we can try to expose a new
EAL function now and refine it in 18.05.
More opinions?
prev parent reply other threads:[~2018-01-26 17:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-31 15:54 [PATCH v1] [app/procinfo] fix memory leak - PCAP & service Vipin Varghese
2018-01-08 12:07 ` Van Haaren, Harry
2018-01-11 19:47 ` [PATCH v2] app/procinfo: Fix memory leak by rte_service_init Vipin Varghese
2018-01-26 15:44 ` Van Haaren, Harry
2018-01-26 16:59 ` [dpdk-stable] " Thomas Monjalon
2018-01-26 17:15 ` Van Haaren, Harry
2018-01-26 17:26 ` Thomas Monjalon [this message]
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=27105962.SPFB230vh8@xps \
--to=thomas@monjalon.net \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=harry.van.haaren@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=olivier.matz@6wind.com \
--cc=stable@dpdk.org \
--cc=vipin.varghese@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.