From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 1/3] kcp: add kernel control path kernel module Date: Mon, 29 Feb 2016 16:27:53 +0100 Message-ID: <10282518.JsUflhI4Jn@xps13> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D42CE5.5000901@intel.com> <56D4618E.4090101@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, Avi Kivity To: Ferruh Yigit Return-path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 4F7406CAE for ; Mon, 29 Feb 2016 16:29:27 +0100 (CET) Received: by mail-wm0-f51.google.com with SMTP id p65so73720536wmp.1 for ; Mon, 29 Feb 2016 07:29:27 -0800 (PST) In-Reply-To: <56D4618E.4090101@redhat.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-02-29 17:19, Panu Matilainen: > On 02/29/2016 01:35 PM, Ferruh Yigit wrote: > > On 2/29/2016 11: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. > >> > > Hi Thomas, > > > > It is great to have some discussion and feedbacks. > > But I doubt not merging in this release will help to have more discussion. > > > > It is better to have them in this release and let people experiment it, > > this gives more chance to better discussion. > > > > These features are replacement of KNI, and KNI is not intended to be > > removed in this release, so who are using KNI as solution can continue > > to use KNI and can test KCP/KDP, so that we can get more feedbacks. > > So make the work available from a separate git repo and make it easy for > people to experiment with it. Code doesn't have to be in a release for > the sake of experimenting, and removing code is much harder than not > adding it in the first place, witness KNI. Good idea. What about a -next tree to experiment on kernel interactions?