> -----Original Message-----
> From: Shreyansh Jain [mailto:shreyansh.j...@nxp.com]
> Sent: Tuesday, April 16, 2019 1:48 PM
> To: Ananyev, Konstantin <konstantin.anan...@intel.com>; Ruifeng Wang (Arm
> Technology China) <ruifeng.w...@arm.com>;
> dev@dpdk.org
> Cc: nd <n...@arm.com>
> Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool
> per port
>
> Hello Ananyev,
>
> > Hi Shreyansh,
> >
> > > > > I tried this patch on MacchiatoBin + 82599 NIC.
> > > > > Compared with global-pool mode, per-port-pool mode showed slightly
> > > > lower performance in single core test.
> > > >
> > > > That was my thought too - for the case when queues from multiple
> > ports
> > > > are handled by the same core
> > > > it probably would only slowdown things.
> > >
> > > Thanks for your comments.
> > >
> > > 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)
> > >
> > > In case there is enough number of cores available for datapath, such
> > segregation can result in better performance - possibly because of
> > > drop in pool and cache conflicts.
> > > At least on some of NXP SoC, this resulted in over 15% improvement.
> > > And, in other cases it didn't lead to any drop/negative-impact.
> >
> > If each core manages just one port, then yes definitely performance
> > increase is expected.
> > If that's the case you'd like enable, then can I suggest to have mempool
> > per lcore not per port?
>
> 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
