Re: [dpdk-dev] [PATCH v2 0/4] recipes for RPM packages

[Neil Horman <nhorman@tuxdriver.com>]

On Thu, May 01, 2014 at 08:53:02AM +0200, Thomas Monjalon wrote:
> 2014-04-30 11:22, Neil Horman:
> > On Wed, Apr 30, 2014 at 01:09:38PM +0200, Thomas Monjalon wrote:
> > > The 4 spec files are used to build 4 different git trees with their own
> > > versioning:
> > > 	http://dpdk.org/browse
> > > 
> > > So I think it's saner to keep them in their repository.
> [...]
> > 
> > Yeah, if they're separate git trees, they can be separate specs.  That said
> > though, it strongly begs the question as to why you are keeping open source
> > pmds outside of the dpdk library?  That really doesn't make much sense, 
> > whats preventing that integration (followed by the integration of the spec
> > files)?
> 
> These extensions have their own versioning.
That doesn't seem to be a reason to keep them separately, in fact if anything
its a reason to merge them so that versioning can be merged.

> They include PMD but also kernel modules (memnic and vmxnet3-usermap).
Thats nothing new.  The DPDK houses several PMD's that require kernel modules
which are stored as part of the DPDK source tree, and built with it

> In case of memnic, the kernel module is an alternative to DPDK PMD. So there 
> is no good reason to integrate it in DPDK.
I don't see what you're saying here.  Just because a given pmd offers an
alternate implementation to simmilar functionality isn't  reason to keep them
separate, its a reason to bring them together.  Users interested in one may well
be interested in the other, and keeping them maintained together offers the
opportunity to merge functionaty more readily.  Regardless of being maintained
in one tree or two, they still offer the user the same thing, by maintaining
them in the same tree you just offer the user a more convienient choice.

> And it's better to host both 
> drivers together in order to keep coherency and share some resources.
Thats a reason to host them in the same tree, not just co-located on the same
server.

> Extensions can also be a place to host some test applications related to its 
> PMD.
> 
Once again, you already do this for the pmd's integrated to the dpdk in the
examples directory, why not do it for the external pmds that you're also
hosting?

> If you see DPDK as a framework, it's really logical to have repositories 
> hosting some projects which are (partly) using the framework.
> 
By your reasoning, if I see DPDK as a framework, none of the PMDs should be
integrated to the dpdk core repository because none of them use every aspect of
the library.  You could certainly do this, and it would be an ok organization,
but it would be a maintenece nightmare, because to update something in the core
library that affected the pmd's would necessitate cloning N git trees for all
the supported PMDs and updating them separately. No new contributors are going
to want that headache. 

All I'm saying here is, you've got several PMD's that are meant to be used with
(and only with) the DPDK, you co-host them on the same git server, their
licensing is compatible/identical, and you're maintaining them.  You're 95% of
the way there, go the extra 5% and integrate them.  What you have currently is
effectively 3 out of tree modules for your library.  As with any out of tree
module, you'll find that, as you grow in contributors maintenece will lag on
those modules, because contibutors wont know (or won't care) to go update the
additional git trees.  It effectively marks them as second class citizens.

Neil