Re: [dpdk-dev] L3fwd mode in testpmd

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

<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