From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 57AEC12A1 for ; Thu, 1 May 2014 12:28:22 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1WfoE0-0001Xk-TM; Thu, 01 May 2014 06:28:25 -0400 Date: Thu, 1 May 2014 06:28:19 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20140501102818.GA14521@hmsreliant.think-freely.org> References: <1398818805-18834-1-git-send-email-thomas.monjalon@6wind.com> <2579041.G0rVZgHGXT@xps13> <20140430152217.GA13937@localhost.localdomain> <127196916.hNrg7ZGWug@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127196916.hNrg7ZGWug@xps13> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 0/4] recipes for RPM packages X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 10:28:22 -0000 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