[dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions

Rahul Gupta rahulgupt at linux.microsoft.com
Sat Feb 3 13:57:49 CET 2024


On (02/02/24 11:21), Thomas Monjalon wrote:
> Date: Fri, 02 Feb 2024 11:21:59 +0100
> From: Thomas Monjalon <thomas at monjalon.net>
> To: Rahul Gupta <rahulgupt at linux.microsoft.com>
> Cc: David Marchand <david.marchand at redhat.com>, dev at dpdk.org,
>  bruce.richardson at intel.com, dmitry.kozliuk at gmail.com,
>  stephen at networkplumber.org, sovaradh at linux.microsoft.com,
>  okaya at kernel.org, sujithsankar at microsoft.com,
>  sowmini.varadhan at microsoft.com, krathinavel at microsoft.com,
>  rahulrgupta27 at gmail.com
> Subject: Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into
>  sub-functions
> 
> 29/01/2024 08:55, David Marchand:
> > On Mon, Jan 29, 2024 at 6:35 AM Rahul Gupta
> > <rahulgupt at linux.microsoft.com> wrote:
> > > > Looking at what this patch does.. I am under the impression all you
> > > > really need is rte_eal_init without initial probing.
> > > > Such behavior can probably be achieved with a allowlist set to a non
> > > > existing device (like for example "-a 0000:00:00.0"), then later, use
> > > > device hotplug.
> > > The patch will be useful to all the adapters irrespective of their
> > > host plug support.
> > 
> > I did not say hotplug support is needed.
> > If what I described already works, this patch adds nothing.
> 
> I agree with David.
> Disabling initial probing should provide what you want.
> Did you test his proposal?
> 
> 
Yes, I was about to reply after testing same, will be done with testing in few days.
But I think the bootup time saved by my patch and hot plug patch will be almost same,
because apart from FLR (probe()) the extra work done by my patch (i.e. telemetry,
rte_service_init() in parallel to mbuf pool creation) are consuming very less bootup time.
So in future if more things are added to 2nd part of eal_init (i.e. rte_eal_init_async_setup()),
then the bootup time will be less if we use my patch.
I think we can defer this patch till then.

Thanks,
Rahul.


More information about the dev mailing list