<snip> > > > > > This discussion has ended up as a stats discussion. But, we also need > to be able to change the configurable parameters easily. > > > > > If we implement the stats and ability to change the configurable > > > > > parameters, then it is essentially bringing in some of the > > > > > capabilities from > > > > testpmd to the sample application. I think that will result in lot more > code in the sample application and will make it complicated. > > > > > > > > > > Instead our proposal is to take L3fwd to testpmd and use all the > > > > > infra code that testpmd provides. We see that this approach > > > > > results in less > > > > amount of code added to DPDK overall. > > > > > > > > > > > > > Agree that it may help testing to have l3fwd support on the testpmd. > > > > > > > > Two concerns, > > > > 1) Testpmd already too complex. > > > > 2) Code duplication. > > > > > > > > For 1), if the l3fwd can be implemented in testpmd as new, > > > > independent forwarding mode, without touching rest of the testpmd, I > think it can be OK. > > > > > > 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 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. > > > > testpmd goal is to test the driver, not the libraries. Agree. I think the L3fwd should be an exception as the performance of this application is a key metric for DPDK.
> > > > > > 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 is not targetted for testing. > > > > Maybe we just lack a new test application for routing libraries? May be. But, I would think the unit tests for the routing libraries should be enough. > > > Yes, I think we do. However, I also think that there are quite a few > advantages to having l3fwding supported in testpmd - particularly in terms of > code reuse, since testpmd already has a lot of the functionality that one > would look for. Furthermore, since testpmd has multiple forwarding engine > support, it makes it very easy to add lpm, hash etc. as separate forwarding > engines, rather than trying to mash them all together into a single one. +1 > > The main downsides are as you point out: > 1. repurposing a PMD-testing app for also helping testing libs. The counter > point here is that for much testing, the key perf metric for a PMD that will > be > looked at is the l3fwd'ing one rather than an iofwd one. > 2. the extra dependencies for testpmd. I think that if we do look to merge in > the extra functionality, we can make the presence of the new forwarding > engine dependent on the presence of the required libs. +1 > > Overall, I'm cautiously in favour of this work, since I believe the benefits > outweigh the disadvantages. Having l3fwd testing in testpmd would also > allow us to consider simplifying l3fwd example so it is more of an example > and less of a "testing-app-masquerading-as-an-example". > > /Bruce
