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

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

Hi 
 
> > > 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). 

Yes.

Probably there is some misunderstanding from my part.
From your previous mail:

"This is applicable for cases where separate cores can handle separate
 ports - each with their pools. (somehow I felt that message in commit
 was adequate - I can rephrase if that is misleading)"

I made a conclusion (probably wrong)
that the only config you are interested  (one that shows performance improvement):
when all queues of each port is managed by the same core and
each core manages only one port.
From that perspective - it doesn't matter would we have pool per core or per port -
we will still end-up with a separate pool per port (and core).
But probably that conclusion was wrong.

> 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.

For generic pools (SW based) having one pool per core should definitely be faster than multiple ones.
For HW based pools - I can't say much, as I don't have such HW to try.
 
> 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).

If my conclusion above was wrong, then yes.
Konstantin