[dpdk-dev] [PATCH v2] librte_pmd_packet: add PMD for AF_PACKET-based virtual devices
nhorman at tuxdriver.com
Fri Nov 14 01:42:08 CET 2014
On Thu, Nov 13, 2014 at 12:57:25PM +0100, Thomas Monjalon wrote:
> 2014-11-13 06:14, Neil Horman:
> > On Thu, Nov 13, 2014 at 02:03:18AM -0800, Thomas Monjalon wrote:
> > > 2014-10-08 15:14, Neil Horman:
> > > > On Wed, Oct 08, 2014 at 05:57:46PM +0200, Thomas Monjalon wrote:
> > > > > 2014-09-29 11:05, Bruce Richardson:
> > > > > > On Fri, Sep 26, 2014 at 10:08:55AM -0400, Neil Horman wrote:
> > > > > > > On Fri, Sep 26, 2014 at 11:28:05AM +0200, Thomas Monjalon wrote:
> > > > > > > > 3) There is no test associated with this PMD.
> > > > > > > That would have been a great comment to make a few months back, though whats
> > > > > > > wrong with testpmd here? That seems to be the same test that every other pmd
> > > > > > > uses. What exactly are you looking for?
> > > > >
> > > > > I was thinking of testing behaviour with different kernel configurations and
> > > > > unit tests for --vdev options. But it's not a major blocker.
> > > > >
> > > > Thats fine with me. If theres a set of unit tests that you have documentation
> > > > for, I'm sure we would be happy to run them. I presume you just want all the
> > > > pmd vdev option exercised? Any specific sets of kernel configurations?
> > >
> > > I don't really know which tests are needed. It could be a mix of unit tests
> > > and functionnal tests described in a test plan.
> > > The goal is to be able to validate the behaviour and check there is no
> > > regression. Ideally some corner cases could be described.
> > > I'm OK to integrate it as is. But future maintenance will probably need
> > > such inputs for validation tests.
> > >
> > Do you have an example set of tests that the other pmd's have followed for this?
> You can check this:
> As I said, we can integrate AF_PACKET PMD without such test plan.
> But we are going to improve testing of many areas in DPDK.
Thank you, I'll take a look in the AM
> > > > > If RedHat is committed for its maintenance, it could integrated in release 1.8.
> > > > > But I'd like it to be renamed as pmd_af_packet (or a better name) instead of
> > > > > pmd_packet.
> > > > >
> > > > John L. is on his way to plumbers at the moment, so is unable to comment, but
> > > > I'll try to get a few cycles to change the name of the PMD around. And yes, I
> > > > thought that maintenance was implicit. He's the author, of course he'll take
> > > > care of it :). And I'll be glad to help
> > >
> > > Do you have time in coming days to rebase and rename this PMD for inclusion
> > > in 1.8.0 release?
> Do you think a sub-tree with pull request model would help you for
> maintenance of this PMD?
I think thats a question for John to answer, but IMHO, I don't think the pmd
will have such patch volume that subtrees will be needed.
More information about the dev