Re: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool per port

[Shreyansh Jain <shreyansh.jain@nxp.com>]

Hi Ananyev,

[...]

> > As you have stated below, it's just the same thing with two different
> views.
> >
> > > I think it would be plausible for both cases:
> > > - one port per core (your case).
> > > - multiple ports per core.
> >
> > Indeed. For this particular patch, I just chose the first one.
> Probably because that is the most general use-case I come across.
> > I am sure the second too has equal number of possible use-cases - but
> probably someone with access to that kind of scenario would be
> > better suited for validating what is the performance increase.
> > Do you think it would be OK to have that in and then sometime in
> future enable the second option?
> 
> What I am trying to say - if we'll have mempool per lcore (not per
> port),
> then it would cover both cases above.
> So wouldn't  need to make extra changes.
> Konstantin

What you are suggesting would end up as 1:N mapping of port:pool (when multiple queues are being used for a port, each affined to different core). In my observation, or rather the cases I generally see, that would end up reducing performance. Especially hardware pools work best when pool:port are co-located.

At least for me this option of setting multiple buffer pools against lcores in l3fwd is NOT a preferred use-case. Which leads me to conclude that we would anyways need both way mapping: pool-per-port and pool-per-core, to cover larger number of use-cases (at least, yours and mine).

Regards,
Shreyansh