[dpdk-dev] [PATCH v2 0/4] recipes for RPM packages
Thomas Monjalon
thomas.monjalon at 6wind.com
Thu May 1 17:13:07 CEST 2014
2014-05-01 06:28, Neil Horman:
> 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
OK I understand you points and I suggest you to open a new thread about it in
few weeks. At the moment, I prefer to concentrate efforts on release 1.6.0r2
and opening version 1.7.0.
Thank you for your involvement
--
Thomas
More information about the dev
mailing list