From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 3898C282 for ; Thu, 3 Mar 2016 09:31:29 +0100 (CET) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id CDF947F08A; Thu, 3 Mar 2016 08:31:27 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-7-148.ams2.redhat.com [10.36.7.148]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u238VP3B000364; Thu, 3 Mar 2016 03:31:25 -0500 To: Thomas Monjalon , Vincent JARDIN References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D6C4BB.3070904@6wind.com> <2396478.VfdoPKd37H@xps13> <5360490.85HbqvIh1a@xps13> From: Panu Matilainen Message-ID: <56D7F65C.7020501@redhat.com> Date: Thu, 3 Mar 2016 10:31:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5360490.85HbqvIh1a@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: dev@dpdk.org, 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 08:31:29 -0000 On 03/03/2016 12:35 AM, Thomas Monjalon wrote: > 2016-03-02 12:21, Thomas Monjalon: >> 2016-03-02 11:47, Vincent JARDIN: >>> Le 02/03/2016 09:27, Panu Matilainen a écrit : >>>>>> 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. >>>>> >>>> >>>> Exactly. >>> >>> +1 too >>> >>> We need to build on this innovation while there is a path for kernel >>> mainstream. The logic of using a staging is a good one. >>> >>> Thomas, >>> >>> can we open a staging folder into the DPDK like it is done into the kernel? >> >> It's possible to create a staging directory if everybody agree. >> It is important to state in a README file or in the doc/ that >> there will be no guarantee (no stable ABI, no validation and can be dropped) >> and that it is a work in progress, a suggestion to discuss with the kernel >> community. >> >> The kernel modules must clearly target an upstream integration. > > Actually the examples directory has been used as a staging for ethtool and > lthread. We also have the crypto API which is still experimental. > So I think we must decide among these 3 solutions: > - no special directory, just mark and document an experimental state > - put only kcp/kdp in the staging directory > - put kcp/kdp in staging and move other experimental libs here To answer this, I think we need to start by clarifying the kernel module situation. Quoting your from http://dpdk.org/ml/archives/dev/2016-January/032263.html: > Sorry the kernel module party is over. > One day, igb_uio will be removed. > I suggest to make a first version without interrupt support > and work with Linux community to fix your issues. This to me reads "no more out-of-tree kernel modules, period" but here we are discussing the fate of another one. If the policy truly is "no more kernel modules" (which I would fully back and applaud) then I think there's little to discuss - if the destination is kernel upstream then why should the modules pass through the dpdk codebase? Put it in another repo on dpdk.org, advertise it, make testing it as easy as possible and all (like have it integrate with dpdk makefiles if needed) instead. The difference with crypto API and ethtool is different in that the destination for them clearly is dpdk itself. I would like to see experimental code moved to a separate (staging or whatever) directory (or a repo/git submodule) to make the situation absolutely clear. Or a repo/git submodule or such. I also still think experimental features should not be enabled by default in the configs, no other project that I know of does that, but that's another discussion. - Panu -