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
