Add more lcores to application after rte_eal_init has been called

Add more lcores to application after rte_eal_init has been called

[Antonio Di Bacco]

I need to add some more cores to the application after the DPDK has
already been initialised.
Is it possible?
For other resources like network cards, I managed to probe new cards
dynamically but don't understand how I can do the same for new lcores.

Re: Add more lcores to application after rte_eal_init has been called

[Stephen Hemminger]

On Wed, 22 Feb 2023 14:10:20 +0100
Antonio Di Bacco <a.dibacco.ks@gmail.com> wrote:

> I need to add some more cores to the application after the DPDK has
> already been initialised.
> Is it possible?

No

> For other resources like network cards, I managed to probe new cards
> dynamically but don't understand how I can do the same for new lcores.

You can start with lots of cores, but only use some of them in your
application. The unused queues could wait on something like pthread_condition
that is blocking.

Re: Add more lcores to application after rte_eal_init has been called

[David Marchand]

On Wed, Feb 22, 2023 at 4:05 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
> On Wed, 22 Feb 2023 14:10:20 +0100
> Antonio Di Bacco <a.dibacco.ks@gmail.com> wrote:
>
> > I need to add some more cores to the application after the DPDK has
> > already been initialised.
> > Is it possible?
>
> No
>
> > For other resources like network cards, I managed to probe new cards
> > dynamically but don't understand how I can do the same for new lcores.
>
> You can start with lots of cores, but only use some of them in your
> application. The unused queues could wait on something like pthread_condition
> that is blocking.
>

If you really want to go with a dynamic approach, you could do like
OVS does which is to stop using EAL threads, but have everything in
your applications: create threads + set their cpu affinity + register
them as lcores.
That's the *easy* part.

Then, if you want to go and only configure the exact number of rxq/txq
wrt to your datapath threads, next is that you need to reconfigure the
existing ports when a change happens and you will need to stop your
existing datapath threads from pulling packets before reconfiguring
the ports.


Stephen description is probably the best/least effort.


-- 
David Marchand