From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ferruh.yigit@intel.com> Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 7D1AF29CF for <dev@dpdk.org>; Thu, 3 Mar 2016 19:19:05 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP; 03 Mar 2016 10:19:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,532,1449561600"; d="scan'208";a="59296051" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.130]) ([10.237.220.130]) by fmsmga004.fm.intel.com with ESMTP; 03 Mar 2016 10:19:00 -0800 To: Stephen Hemminger <stephen@networkplumber.org> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D420E5.9010802@intel.com> <56D42462.3020905@scylladb.com> <1945473.Tiatd2m80T@xps13> <CADNuJVof3FmLHsJG2MkViLpF0dr28PB6NZdVC7=vB+ZExHfO3w@mail.gmail.com> <20160301180255.3ef1a17e@xeon-e3> <CADNuJVr3hxSS4ctmvfb_EJSGuDj-0DFSemzp-2aejBjC9k7FYw@mail.gmail.com> <56D80DED.8040909@intel.com> <20160303085915.517441f8@xeon-e3> From: Ferruh Yigit <ferruh.yigit@intel.com> Message-ID: <56D8800A.6000502@intel.com> Date: Thu, 3 Mar 2016 18:18:50 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160303085915.517441f8@xeon-e3> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: DPDK <dev@dpdk.org>, Avi Kivity <avi@scylladb.com> Subject: Re: [dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module 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, 03 Mar 2016 18:19:06 -0000 On 3/3/2016 4:59 PM, Stephen Hemminger wrote: > On Thu, 3 Mar 2016 10:11:57 +0000 > Ferruh Yigit <ferruh.yigit@intel.com> wrote: > >> On 3/2/2016 10:18 PM, Jay Rolette wrote: >>> >>> On Tue, Mar 1, 2016 at 8:02 PM, Stephen Hemminger >>> <stephen@networkplumber.org <mailto:stephen@networkplumber.org>> wrote: >>> >>> On Mon, 29 Feb 2016 08:33:25 -0600 >>> Jay Rolette <rolette@infiniteio.com <mailto:rolette@infiniteio.com>> >>> wrote: >>> >>> > On Mon, Feb 29, 2016 at 5:06 AM, Thomas Monjalon >>> <thomas.monjalon@6wind.com <mailto:thomas.monjalon@6wind.com>> >>> > wrote: >>> > >>> > > Hi, >>> > > I totally agree with Avi's comments. >>> > > This topic is really important for the future of DPDK. >>> > > So I think we must give some time to continue the discussion >>> > > and have netdev involved in the choices done. >>> > > As a consequence, these series should not be merged in the >>> release 16.04. >>> > > Thanks for continuing the work. >>> > > >>> > >>> > I know you guys are very interested in getting rid of the out-of-tree >>> > drivers, but please do not block incremental improvements to DPDK >>> in the >>> > meantime. Ferruh's patch improves the usability of KNI. Don't >>> throw out >>> > good and useful enhancements just because it isn't where you want >>> to be in >>> > the end. >>> > >>> > I'd like to see these be merged. >>> > >>> > Jay >>> >>> The code is really not ready. I am okay with cooperative development >>> but the current code needs to go into a staging type tree. >>> No compatibility, no ABI guarantees, more of an RFC. >>> Don't want vendors building products with it then screaming when it >>> gets rebuilt/reworked/scrapped. >>> >>> >>> That's fair. To be clear, it wasn't my intent for code that wasn't baked >>> yet to be merged. >>> >>> The main point of my comment was that I think it is important not to >>> halt incremental improvements to existing capabilities (KNI in this >>> case) just because there are philosophical or directional changes that >>> the community would like to make longer-term. >>> >>> Bird in the hand vs. two in the bush... >>> >> >> There are two different statements, first, code being not ready, I agree >> a fair point (although there is no argument to that statement, it makes >> hard to discuss this, I will put aside this), this implies when code is >> ready it can go in to repo. >> >> But not having kernel module, independent from their state against what >> they are trying to replace is something else. And this won't help on KNI >> related problems. >> >> Thanks, >> ferruh >> > > Why not re-submit patches but put in lib/librte_eal/staging or similar path > and make sure that it does not get build by normal build process. > I will do when staging is ready/defined. Also will start working on upstreaming modules. Thanks, ferruh