From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <olivier.matz@6wind.com> Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id A31B22BB2 for <dev@dpdk.org>; Fri, 24 Feb 2017 15:26:08 +0100 (CET) Received: by mail-wm0-f43.google.com with SMTP id v186so15825928wmd.0 for <dev@dpdk.org>; Fri, 24 Feb 2017 06:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=UYylzyTmZlurH/u4t0BOIU2UV/rHf4fzV35z3xcjjT0=; b=oyuySUqEk8cnukuJmZuyuXQ7CguGL4FdJ5tB0yBl23OdYW1pH4IhkJbfq0rTRKnSsm qB/Om6bR/0tyxNoojsDkR7ja+ApAusYZ5xX0JqN4s+rWEsX+SNtuxpQxVue+bhRBNgmy 5+gpWKsYSdL/VMaVx3SwgoPiHti1fuNSo1a2Ho5uYvBXtzWcOU0eYdrYpZZ8I6hEj0Nf CjXiVFEmVHeXIsR+Xq6fY+fdoGxCJSfDTmn5Ue/EFIN87WdxMp5Iu4gKSPhvek5CQ8ua SwQm+WJjPhwAUJobXbXsUw6M24n1KwIg97HsGcIdCh/WVsrsNi7GqxNvps+Cd8LMalXz GbDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=UYylzyTmZlurH/u4t0BOIU2UV/rHf4fzV35z3xcjjT0=; b=lwKatv7UqqfcXyQSFLD5HkX8hpcveYE3PKsN3AkRJv6hLTrIUFAe00QlWH1Dy9anrw SBgOhdamdd+ZdohoSOm4ElLfyFoU9Pl4ScmgSz/XyeTePDwE6XEG61s4dpjQif1kgVWn Axz/QG45sQ9ciH+LZIw7fwzWAAZKyY9K7jRI9i1x8nmmfWcoKnxm1goqmMSjHdUEXiNE u4hpsq8xZAA1kVUGbhA6fIaQ+CkpOWqWXn3xwGKQLdar1f4nosf/B86eMNpwcZKDsFie Glj0RAwUhi0qQjebrszf7wOIP0SC4Vo1F09fRQhFd6oLmCB2+YHOYVGxaCnEq2wyN2M4 OnDg== X-Gm-Message-State: AMke39mXOIoIoki5WPgkB4pkHnIjgI8Z9CtYGlIYJdIwc2fOr+3KSbh7fcAnV2kPdhH0d0kz X-Received: by 10.28.169.142 with SMTP id s136mr2869115wme.9.1487946368334; Fri, 24 Feb 2017 06:26:08 -0800 (PST) Received: from platinum (2a01cb0c03c651000226b0fffeed02fc.ipv6.abo.wanadoo.fr. [2a01:cb0c:3c6:5100:226:b0ff:feed:2fc]) by smtp.gmail.com with ESMTPSA id d29sm2550730wmi.19.2017.02.24.06.26.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 24 Feb 2017 06:26:08 -0800 (PST) Date: Fri, 24 Feb 2017 15:26:05 +0100 From: Olivier Matz <olivier.matz@6wind.com> To: Bruce Richardson <bruce.richardson@intel.com> Cc: Remy Horton <remy.horton@intel.com>, "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>, Thomas Monjalon <thomas.monjalon@6wind.com>, "dev@dpdk.org" <dev@dpdk.org> Message-ID: <20170224152605.415db31e@platinum> In-Reply-To: <20170224132546.GB97552@bricha3-MOBL3.ger.corp.intel.com> References: <59AF69C657FD0841A61C55336867B5B035B99794@IRSMSX103.ger.corp.intel.com> <3736276.ftqFo2Af7c@xps13> <20170221134658.GA208676@bricha3-MOBL3.ger.corp.intel.com> <1746585.AAhpvkiIzm@xps13> <3EB4FA525960D640B5BDFFD6A3D89126527526E0@IRSMSX108.ger.corp.intel.com> <4322b761-83d7-2e23-5fdc-c5b493a95ca2@intel.com> <20170224141731.25d7a618@platinum> <20170224132546.GB97552@bricha3-MOBL3.ger.corp.intel.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] decision process to accept new libraries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <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: Fri, 24 Feb 2017 14:26:08 -0000 On Fri, 24 Feb 2017 13:25:46 +0000, Bruce Richardson <bruce.richardson@intel.com> wrote: > On Fri, Feb 24, 2017 at 02:17:31PM +0100, Olivier Matz wrote: > > On Fri, 24 Feb 2017 11:33:11 +0000, Remy Horton > > <remy.horton@intel.com> wrote: > > > On 22/02/2017 19:06, Dumitrescu, Cristian wrote: > > > [..] > > > > This essentially leads to the "other" repos becoming second > > > > class citizens that can be broken at any time without prior > > > > notice or the right to influence the change. The amount of > > > > maintenance work becomes very difficult to quantify (e.g. we > > > > all know what a ripple effect a chance in the mbuf structure > > > > can cause to any of those "other" DPDK libraries). > > > > > > +1 - In my experience anything other than a single repository > > > ends up in tears sooner or later. At a previous company I worked > > > on a project where each "module" went into its own repo, all > > > fourty-five of which were strung together using Gerrit/Jenkins, > > > the result being I spent more time on rebases and build breakages > > > than writing business logic. Patchsets that cross repo boundaries > > > are a recipe for pain, and if DPDK goes down the same route, it > > > will likley cripple development. > > > > On the other hand, I think we can agree that everything that > > depends on dpdk cannot be hosted in dpdk repository. > > > > Many applications are hosted in other repositories: for instance > > pktgen or vpp. A given version of these applications runs on a > > given version of dpdk. It could also applies for libraries. > > > > Having apps/libs outside the dpdk repo is more work for their > > maintainers because they may need to revalidate (compilation + > > test) for each dpdk version. Having them inside the dpdk repo is > > more work for the maintainers of dpdk core libs, because they need > > to update all of them when they do a big changes. This is sometimes > > not doable because they don't have a test platform or knowledge for > > each pmd or lib. > > Maybe not, and I wouldn't expect someone making a change to have to > test every library affected by the change. However, I would expect > them to have enough knowledge of the change being made to update the > affected code in other libraries in a semi-mechanical way, and ensure > it compiles. If you are changing a core library and are not able to > change all uses of the API yourself, then you really need to question > if the change is a good one or not, or if you are qualified to make a > change if you don't understand how the old code was being used. Yes. But the problem is when the guy that wants to do the change is aware that he/she does not have the skills to update all the libraries. At the end, the change may never be done because of the amount of work. I can give some examples: - remove the m->port field (requires to update some examples which hijack this field, maybe also some libs) - move some mbuf fields in the second cache line (requires to update all the PMDs, including vector ones) However I agree with what you said on the content :) I just want to highlight that both approaches have their advantages and drawbacks. And because to me there is no easy answer, I think it's sage to let this decision to the technical board. > > I also think it's likely that many users of DPDK code will have legacy > code using DPDK, for which the original programmer may be the one > making any updates. If, again, the change is such that it can't be > done in a relatively mechanical way, that is going to be a problem > for all those users. > > As for review and testing, that is the responsibility of the > maintainers and validators responsible for the individual library > being updated. > > /Bruce >