From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id 31BDD6833 for <dev@dpdk.org>; Thu, 1 May 2014 17:13:04 +0200 (CEST) Received: by mail-wi0-f181.google.com with SMTP id f8so899340wiw.2 for <dev@dpdk.org>; Thu, 01 May 2014 08:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=RykoyRLWCHSRjE87GmwUYQzD9phAJD4n/t3JMKJdydg=; b=cC1NURh9k7vcMMuOcLg9R0++70ChNGueJQ3a6Ro8FPRikMZKgBsbJEhxbrN/soaj/7 zjhOvTNOfiiqtIhQgqLWHhjBGOlws295Q1C/x9pu22EbhvVOHeWWcr8WSEM18bpPpfVb hioKz1MnBgHIZTLys3bvIN5PV1DFDjwkQS7f4n7wfz0bGrCUMnv6k6HOAc9+qmsF0Lz0 8ypzJTpRSO83lYCH4Pa8pQ7Zmrr7+jKSKS2TxOxUQRsvrsX+Pcpe6VqS0f/sngI9wsOG 7K9aHdhSMD5S4LLRstpecDG9RtKgj5oX/gIa9G+i+8+oWZT39sPA4e7UPAhzHjZe2kSs 48JA== X-Gm-Message-State: ALoCoQkVIMvKEzevxS+CasD2ybcuRN4c9gI/SSdKJoOJdMzDZHRXF2t/oZBFiitmi2GJCDlHuB2+ X-Received: by 10.180.91.161 with SMTP id cf1mr2516334wib.49.1398957188046; Thu, 01 May 2014 08:13:08 -0700 (PDT) Received: from xps13.localnet (abo-213-55-68.mts.modulonet.fr. [85.68.55.213]) by mx.google.com with ESMTPSA id gc19sm4283024wic.5.2014.05.01.08.13.06 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 May 2014 08:13:07 -0700 (PDT) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: Neil Horman <nhorman@tuxdriver.com> Date: Thu, 01 May 2014 17:13:07 +0200 Message-ID: <6913132.1jrAsoTm4Y@xps13> Organization: 6WIND User-Agent: KMail/4.13 (Linux/3.14.1-1-ARCH; KDE/4.13.0; x86_64; ; ) In-Reply-To: <20140501102818.GA14521@hmsreliant.think-freely.org> References: <1398818805-18834-1-git-send-email-thomas.monjalon@6wind.com> <127196916.hNrg7ZGWug@xps13> <20140501102818.GA14521@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 01 May 2014 15:13:04 -0000 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