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
