From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: [PATCH 1/3] kcp: add kernel control path kernel module Date: Mon, 29 Feb 2016 18:04:32 +0200 Message-ID: <56D46C10.6010902@redhat.com> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D42CE5.5000901@intel.com> <56D4618E.4090101@redhat.com> <10282518.JsUflhI4Jn@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Avi Kivity To: Thomas Monjalon , Ferruh Yigit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id B39C6952 for ; Mon, 29 Feb 2016 17:04:34 +0100 (CET) In-Reply-To: <10282518.JsUflhI4Jn@xps13> 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" On 02/29/2016 05:27 PM, Thomas Monjalon wrote: > 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? Here's another, related but more radical (and rather unbaked) idea: Move all the kernel modules and their associated libraries (thinking of KNI here) to a separate repo with perhaps more relaxed rules, but OTOH require upstream kernel support for any features to be included in dpdk itself. Carrot-and-stick of sorts :) - Panu -