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
