From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 57AFE29CA for ; Tue, 12 Sep 2017 10:48:40 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E995E20BE4; Tue, 12 Sep 2017 04:48:39 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 12 Sep 2017 04:48:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=CybyLXGiJGYqFsA PDF7tUCaHqRk/aqtGPSYWu8fbjn4=; b=pUttzw4ynej/eO3xS9dHG7/jfY76VTb yfnhRnYIFu/uXqPWY8JwMGabyFcIEASHajIdGsSQOssnQplxAFuv5ds2zEjl1Yub 6YnDmLU8dYNprEnkD9ERKYg5YUFJy84QiU0aAHyQGUKCNrXzzM71LzKhvhRxIj/N SSZnMFa4AL3Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=CybyLXGiJGYqFsAPDF7tUCaHqRk/aqtGPSYWu8fbjn4=; b=XYPhFSh8 qdNP9Wx1yz7pT1X8sDnAKmO0auBYDucC86b1SNyuD5ES7/f0cvYQmA8nkYul7yTn o4/9NbYifyc2MSibCotoWbu1bm40d3p8V3DIFAipozaTgTiop9hWttcgKSjXuq2P 6Udp8qjWqRdneHQaU+oVUu6J4xx3/52Yiz98e9cF7KzqygtmqAnWunzx0IVxQW8n mNw+4rUEXfkpoWQEhq8Ke0guAURPdcr6Dg/rFXbBLSv838RkFAQohiptUOjXkp7Y YIUQSVzjvmfkuAK1akVi0feV1rYjjaOXZD/cj9mLvqV19/DFHaK6RCVimTd0/Y/F IgoSR854jUaKqA== X-ME-Sender: X-Sasl-enc: r/MOIQEcVVDcZ0a44YYzOBStR8l2iTgkZl0JSqUZpUc2 1505206119 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A6A127FA7D; Tue, 12 Sep 2017 04:48:39 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: ferruh.yigit@intel.com, stephen@networkplumber.org, dev@dpdk.org Date: Tue, 12 Sep 2017 10:48:38 +0200 Message-ID: <1536607.mpdSPqACls@xps> In-Reply-To: <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> References: <2737351.pD9poAUtZC@xps> <20170912083207.GC40060@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] git trees organization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 08:48:40 -0000 12/09/2017 10:32, Bruce Richardson: > On Tue, Sep 12, 2017 at 12:03:30AM +0200, Thomas Monjalon wrote: [...] > > At the same time, we can think how to add more git sub-trees: > > In principle, I'm in favour, but I think that the subtrees of the master > tree should be at a fairly coarse granularity, and not be too many of > them. The more subtrees, the more likely we are to have issues with > patchsets needing to be split across trees, or having to take bits from > multiple trees in order to test if everything is working. > > > Should we create next-net-intel for Intel networking drivers? > > Given the number and size of intel drivers, this seems reasonable to > start as a second-level subtree. OK, we need the name of a volunteer :) > > Any volunteer? > > > > Should we create next-bus for bus API and drivers? > > Stephen Hemminger is working on a new bus. > > Would you be interested by taking the responsibility of this git tree? > > Is this something that is going to need ongoing work and maintenance, or > just something that would be needed while the current rework of > introducing bus types is being done? If the former, a tree makes sense, > but not if it's the latter case. We are going to have many bus drivers (pci, vdev, fslmc, vmbus). If we look only at PCI, there are always some new patches to improve or fix things. So I think it is reasonnable to imagine that we will have some real activity with all bus drivers. > > Should we create next-mem for malloc/mempool? > > > Core libs tree, encompassing eal, mempool and 1 or 2 others? I don't > think memory should have its own tree initially. > > > Should we take ethdev patches into next-net? > > Definitely! I think not doing so was a bit of a mistake when net tree > was spun off. Sure it was a mistake, but it was assumed because net drivers is already a big work. I hope we can add it now while moving Intel drivers to a second level sub-tree. > > Other suggestions? > > Similar to above, cryptodev should be in crypto tree, eventdev in event > tree etc. It is already the case. No change to do here :) > Other than that, all I can say is "let's do it!". We have quite a > backlog to get through for 17.11, so anything that moves things along > faster is to be welcomed. Yes!