[dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd

[Wang, Zhihong]

> -----Original Message-----
> From: Richardson, Bruce
> Sent: Thursday, April 21, 2016 7:00 PM
> To: Thomas Monjalon <thomas.monjalon at 6wind.com>
> Cc: Wang, Zhihong <zhihong.wang at intel.com>; dev at dpdk.org; De Lara Guarch,
> Pablo <pablo.de.lara.guarch at intel.com>
> Subject: Re: [dpdk-dev] [RFC PATCH 0/2] performance utility in testpmd
> 
> On Thu, Apr 21, 2016 at 11:54:12AM +0200, Thomas Monjalon wrote:
> > 2016-04-20 18:43, Zhihong Wang:
> > > This RFC patch proposes a general purpose forwarding engine in testpmd
> > > namely "portfwd", to enable performance analysis and tuning for poll mode
> > > drivers in vSwitching scenarios.
> > >
> > >
> > > Problem statement
> > > -----------------
> > >
> > > vSwitching is more I/O bound in a lot of cases since there are a lot of
> > > LLC/cross-core memory accesses.
> > >
> > > In order to reveal memory/cache behavior in real usage scenarios and enable
> > > efficient performance analysis and tuning for vSwitching, DPDK needs a
> > > sample application that supports traffic flow close to real deployment,
> > > e.g. multi-tenancy, service chaining.
> > >
> > > There is a vhost sample application currently to enable simple vSwitching
> > > scenarios, it comes with several limitations:
> > >
> > >    1) Traffic flow is too simple and not flexible
> > >
> > >    2) Switching based on MAC/VLAN only
> > >
> > >    3) Not enough performance metrics
> > >
> > >
> > > Proposed solution
> > > -----------------
> > >
> > > The testpmd sample application is a good choice, it's a powerful poll mode
> > > driver management framework hosts various forwarding engine.
> >
> > Not sure it is a good choice.
> > The goal of testpmd is to test every PMD features.
> > How far can we go in adding some stack processing while keeping it
> > easily maintainable?
> 
> I was thinking the exact same thing. Would it not be better to enhance the
> existing vhost example application to remove the limitations you call out above?
> I don't particularly like the idea of introducing protocol awareness into testpmd
> for IP forwarding, for instance.


Hi Bruce,

I understand the concern.

Like I mentioned in the original thread, this utility is not for vSwitching
in particular, it's just adding more forwarding setup capabilities in testpmd.

testpmd composes of separated components:
1) pmd management framework
2) forwarding engines:
   a) traffic setup
   b) forwarding function

When adding a new fwd engine, only the new traffic setup function and
forwarding function (maybe cmd handlers too) are added, no existing
things are touched. So it doesn't make it harder to maintain.

It doesn't change the current behavior at all, by default it's still iofwd,
the user can switch to portfwd only when flexible forwarding rules are
needed.


I understand that testpmd was positioned to provide test framework
for pmds, and it's no harm to keep it that way. But I think testpmd has
already become a widely used tool to setup performance and functional
test in both DPDK and OVS-DPDK community. It can do more with simple
changes like this.

There're benefits to enhance forwarding capabilities of testpmd, like,
people can build up DPDK performance/functional test more easily,
in both host and guest; also it eliminates overheads in apps like OVS to
test what DPDK can provide in real scenarios for analysis.


With the vhost pmd feature, testpmd has become a vSwitch already,
we just need to add more forwarding setup capability to make use of it.

If we modify the current vhost sample to do this, then we basically just
re-implement what testpmd has already provided all over again, which
introduces duplicated efforts and increases maintenance work because
what's changed in testpmd may need to go into that sample too.


Thanks
Zhihong


> 
> 	Regards,
> 	/Bruce