From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by dpdk.org (Postfix) with ESMTP id 132162B97 for ; Thu, 3 Mar 2016 17:59:04 +0100 (CET) Received: by mail-pa0-f52.google.com with SMTP id bj10so17814705pad.2 for ; Thu, 03 Mar 2016 08:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TGKTWrTE8bOvPtXEvnkeJ/ur3xDB4wv5aSV0IDWBvOo=; b=MWt5aUFWH23fP4wpzPZWx31O3LBikXAL0BqVnzcMyUtGexIDRXDp2i+q2FZUciRvEl B+A8hpaKWeBQNKVfD8qfBmWT0PCwH3WKxjA/jgRT+oJS7MnB2PWk8ya78yzKDKY+g4qc fJDnuKGiaM2r13hr/UAzrDaSef3L8f82USoD+Bl7yApSxK87QBbnJOnpiwma+bZaCZ/t KR8Abg9K/eIPHGk/twqyHQwXQ84NDSdFcEbxuzM1LgZ0LoBkaVqbd5pitPrEJETRV11F 1t+lggiktoikcoHj5nLvwlEgE1S3zzSAMNJJBM19gzHU5V7v0neDrZXwxDNTFgDQe//m u/sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TGKTWrTE8bOvPtXEvnkeJ/ur3xDB4wv5aSV0IDWBvOo=; b=hThhBqUgan+YRQTvY7iye5XPPOoq4entBqBoWmtzxN7gboAhuk3w92z0P6PTMGxx1R Qk3GXTDxzD1IPKotc3BoW3uhRpYGfyJ1DMgwC7XuYnOwH5UNdUvhdrJLP47WNU/0sc6W lOVx1QHW34COfoDOCvvRqF/5tDhP2ql71EuX2uEHLrVxZVupOjpRUvLjRKGBsacqsxVi fmdq6d91zssCivZy5ySuc64Z9Yzn4aZHGygdoLiJFLVZfs21YIYPJyKWfvlCQKIQbykT fIovnhVi4+DgYJQGmnfVnXjTPhagGiRk/j6AlxNqLPtC34sipETgDKa3AFwZjWanNbyB g53w== X-Gm-Message-State: AD7BkJKhAoNLG/Cte02NGzspzmkVvB7bOdYQPiMlJA0B2iwyYgGYQYlQ8DbJ3X7rDZdCLQ== X-Received: by 10.66.160.7 with SMTP id xg7mr5026211pab.10.1457024343343; Thu, 03 Mar 2016 08:59:03 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id ti6sm61893068pab.4.2016.03.03.08.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Mar 2016 08:59:02 -0800 (PST) Date: Thu, 3 Mar 2016 08:59:15 -0800 From: Stephen Hemminger To: Ferruh Yigit Message-ID: <20160303085915.517441f8@xeon-e3> In-Reply-To: <56D80DED.8040909@intel.com> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D420E5.9010802@intel.com> <56D42462.3020905@scylladb.com> <1945473.Tiatd2m80T@xps13> <20160301180255.3ef1a17e@xeon-e3> <56D80DED.8040909@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: DPDK , Avi Kivity 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:59:04 -0000 On Thu, 3 Mar 2016 10:11:57 +0000 Ferruh Yigit wrote: > On 3/2/2016 10:18 PM, Jay Rolette wrote: > > > > On Tue, Mar 1, 2016 at 8:02 PM, Stephen Hemminger > > > wrote: > > > > On Mon, 29 Feb 2016 08:33:25 -0600 > > Jay Rolette > > > wrote: > > > > > On Mon, Feb 29, 2016 at 5:06 AM, Thomas Monjalon > > > > > > 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.