<snip> > > > > > > > > > In fact, l3fwd is also quite big and complex: > > > $ wc -l examples/l3fwd/*.[h,c] |grep total > > > 6969 total > > > > > > Plus it will introduce extra dependencies (fib, lpm, hash, might-be > > > acl?) I am not sure it is a good idea to pull all these complexities into > > > test- > pmd. > > I do not suggest pulling all these in. In our case, I see that the ask is > > only on > LPM. I am open to hearing what others see as the requirement. > > Ok, but l3fwd forwarding model is quite different from current PMD one > (egress queue selection, TX packets buffering, etc.). > I suppose you'll need to pull all that too from l3fwd? We will send an RFC to show what it looks like.
> > > > > > I can't imagine that l3fwd app need ability to configure each and > > > every PMD parameter. > > > From my experience in l3fwd most of cycles are spent not in PMD > > > itself, but in actual packet processing: header parsing and > > > checking, classification, routing table lookup, etc. > > During our work, we had to experiment with burst size, rx/tx queue > > depths along with other PMD specific configuration parameters. The packet > processing code remains the same and there is not much to optimize. > > I think burst-size and rx/tx queue size can be added into l3fwd as new config > parameters. > Doesn't look like a major issue to me. > PMD specific parameters could be a problem... anything particular you plan > to use? We are talking about debugging the performance problem which needs all the flexibility possible. > > > > > > > > Not sure how to address 2), also lets say we want to add new > > > > feature to l3fwd, where it should go, to the sample or to the testpmd? > > L3fwd example will remain as the example. We have to duplicate the > > code into testpmd. If L3fwd example is changed, it needs to be changed in > testpmd as well. > > Usually code duplication is not a good sign. > I understand that sometimes it is unavoidable, but why we have to do it > here?
