From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 29E385A35 for ; Thu, 15 Jan 2015 22:55:04 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 15 Jan 2015 13:55:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,406,1418112000"; d="scan'208";a="637977406" Received: from irsmsx155.ger.corp.intel.com ([163.33.192.3]) by orsmga001.jf.intel.com with ESMTP; 15 Jan 2015 13:55:01 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.213]) by IRSMSX155.ger.corp.intel.com ([169.254.14.228]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 21:55:00 +0000 From: "O'driscoll, Tim" To: Neil Horman , Thomas Monjalon Thread-Topic: [dpdk-dev] Why nothing since 1.8.0? Thread-Index: AQHQMDgkRICerg8+NU+uGsyD3xhjm5zAGjKAgAB5GwCAAANIgIAAWrAAgAA2YQCAAEhygIAAF++AgAAuIsA= Date: Thu, 15 Jan 2015 21:55:00 +0000 Message-ID: <26FA93C7ED1EAA44AB77D62FBE1D27BA54C9978E@IRSMSX102.ger.corp.intel.com> References: <20150114122352.63ef79eb@urahara> <1717148.0lUn7GOqmp@xps13> <20150115130616.GA22455@hmsreliant.think-freely.org> <12253538.YOLaLVcskf@xps13> <20150115185112.GC22455@hmsreliant.think-freely.org> In-Reply-To: <20150115185112.GC22455@hmsreliant.think-freely.org> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] Why nothing since 1.8.0? 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, 15 Jan 2015 21:55:04 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman > Sent: Thursday, January 15, 2015 6:51 PM > To: Thomas Monjalon > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] Why nothing since 1.8.0? >=20 > On Thu, Jan 15, 2015 at 06:25:33PM +0100, Thomas Monjalon wrote: > > 2015-01-15 08:06, Neil Horman: > > > On Thu, Jan 15, 2015 at 10:51:38AM +0100, Thomas Monjalon wrote: > > > > 2015-01-15 04:27, Ouyang, Changchun: > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhang, Helin > > > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil > Horman > > > > > > > On Wed, Jan 14, 2015 at 12:23:52PM -0800, Stephen Hemminger > wrote: > > > > > > > > Ok, so 1.8.0 came out almost a month ago and none of the > patches > > > > > > > > that were deferred waiting for the release got merged since > then. > > > > > > > > Last commit in git is the 1.8.0 release. > > > > > > > > > > > > > > > > Where is the post-merge window bundle, where are the later > commits? > > > > > > > > Lots of patches are sitting rotting in patchwork... > > > > > > > > > > > > > > +1, I've had the same questions. > > > > > > > Neil > > > > > > > > > > > > +1, Some patch set might be ready for being merged. > > > > > > > > > > +1, the earlier some patches are merged into mainline, and the e= asier > those > > > > > sequent patch sets can resolve their conflicts. > > > > > > > > +1, there are some patches which are properly reviewed > > > > > > > > Reminder: sub-tree to manage specific part of DPDK can be open on > request > > > > > > Ok, I think what you're saying here is you're too busy to handle all = the > patches > > > comming in at the moment. As such I'd like to propose a sub-tree > encompassing > > > all the pmds in DPDK. I would envision that including all the acutal= pmd's > in > > > the tree, as well as the infrastructure that is used to interface the= m to the > > > core (i.e. the ethdev/rte_ether library). I'll gladly maintain the p= atch pool > > > and send you pull requests. > > > > The list of PMDs is increasing: > > librte_pmd_af_packet > > librte_pmd_bond > > librte_pmd_e1000 > > librte_pmd_enic > > librte_pmd_i40e > > librte_pmd_ixgbe > > librte_pmd_pcap > > librte_pmd_ring > > librte_pmd_virtio > > librte_pmd_vmxnet3 > > librte_pmd_xenvirt > > There is already some sub-trees for bnx2x, fm10k and i40e: > > http://dpdk.org/browse/ > > > Yes, and I've mentioned before that that is an absolutely silly way to br= eak > out > subtrees. You have to find a balance of workload distribution and develo= per > convienience. >=20 > I also note that these are problematic because you're not merging anythin= g > from them. Is it your intention to keep bnx2 and fm10k separate in > perpituity? > If so, thats a real problem, because then we effectively just have severa= l out > of tree drivers, and thats just unacceptible. >=20 > > > If you could set me up with a login to dpdk.org, I'd appreciate it. > > > > It is preferred to have 1 sub-tree per module. > > What do you think of managing contributions for af_packet and/or virtio= ? > > It would make sense as virtio is a RedHat technology. > > Maybe it could include vhost lib and example. > > > No, for reasons I've mentioned before. If you take each pmd/library and > create > a subtree for it, you've created the most fine grained control of subtree= s you > could ask for, but you've created a nighmare of a burden on developers wh= o > want > to update any code, especially if they have patches that hit multiple tre= es. >=20 > Look at some of the stats in the dpdk tree: >=20 > Library Commits between 1.7.0 and 1.8.0 > librte_acl 5 > librte_cfgfile 0 > librte_cmdline 4 > librte_compat 0 > librte_distributor 5 > librte_eal 125 > librte_ether 31 > librte_hash 1 > librte_ip_frag 5 > librte_ivshmem 0 > librte_kni 2 > librte_kvargs 0 > librte_lpm 1 > librte_malloc 1 > librte_mbuf 39 > librte_mempool 4 > librte_meter 0 > librte_net 4 > librte_pipeline 0 > librte_pmd_af_packet 4 > librte_pmd_bond 20 > librte_pmd_e1000 21 > librte_pmd_enic 12 > librte_pmd_i40e 90 > librte_pmd_ixgbe 83 > librte_pmd_pcap 4 > librte_pmd_ring 0 > librte_pmd_virtio 21 > librte_pmd_vmxnet3 21 > librte_pmd_xenvirt 6 > librte_port 6 > librte_power 3 > librte_ring 2 > librte_sched 1 > librte_table 7 > librte_timer 0 > librte_vhost 30 >=20 > If you look at all of the pmds in the dpdk tree, we're talking about ~300 > patches per release. If you look at the net-next tree for the linux kern= el, > Dave Miller merged 569 patches on his own (based on the following > command: > git log --pretty=3Dformat:%H v3.17..v3.18 -- drivers/net/ethernet/ net/co= re/ | > wc > -l) >=20 > And that doesn't account for the ~500 patches that come in via pull reque= st > from > the wireless subtree. Nor does it account for the merge window for net- > next > being 2 months instead of dpdk's 6 months. Theres no need in any way for > 12 > maintainers to be twiddling their thumbs waiting on ~20 patches each, and > for > that split, you've forced developers to potentially develop patches again= st 12 > trees (12 being the current number of PMD's that are in the dpdk). >=20 > The right answer here is balance. Let me split out the pmd's and etherne= t > infrastructure libraries to a subtree. I'll pull in patches posted regar= ding > pmd's and librte_ether/ip_frag etc, and send you a pull requests after ea= ch > release so you get all the latest bits, and then pulls for stabilization = on each > -rc. I can manage 300 patches without issue, and that takes a load off yo= ur > shoulders. I'll get fm10k integrated, as well as bnx2. That gives us a = single > alternate tree for developers to go to for pmd and pmd infrastructure > updates. > Its a win-win. >=20 > Regards > Neil I agree with Thomas on this. The approach we've been taking for PMDs for ne= wer Intel NICs is to have a separate sub-repository with a maintainer who's= an expert in the area. This offloads some work from Thomas, ensures that t= he maintainer is very familiar with the PMD code and the corresponding hard= ware, and doesn't involve too much additional work for the developers invol= ved (as you said, there isn't a huge volume of commits for any individual P= MD). We have this in place for i40e now, and will be applying this to fm10k= , which hasn't been upstreamed yet but will be in time for the 2.0 release.= Based on our experiences with those, we may well look at extending the mod= el to include PMDs for other Intel NICs, and possibly other libraries, as w= ell. As you said, there's a balance to be struck, and too many subtrees may beco= me unmanageable. With respect to your concern about developers having to po= tentially develop patches against multiple subtrees, this has never been ra= ised as a concern by any of our development team. Is there any historical d= ata on the number of changes that would fall into this category so we can s= ee if it's a real problem or not? Tim