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: Thu, 3 Mar 2016 10:31:24 +0200 Message-ID: <56D7F65C.7020501@redhat.com> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D6C4BB.3070904@6wind.com> <2396478.VfdoPKd37H@xps13> <5360490.85HbqvIh1a@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Avi Kivity To: Thomas Monjalon , Vincent JARDIN 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) In-Reply-To: <5360490.85HbqvIh1a@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 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 =C3=A9crit : >>>>>> I'd like to see these be merged. >>>>>> >>>>>> Jay >>>>> >>>>> The code is really not ready. I am okay with cooperative developmen= t >>>>> 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 k= ernel? >> >> 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 dr= opped) >> and that it is a work in progress, a suggestion to discuss with the ke= rnel >> 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=20 situation. Quoting your from=20 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=20 we are discussing the fate of another one. If the policy truly is "no more kernel modules" (which I would fully=20 back and applaud) then I think there's little to discuss - if the=20 destination is kernel upstream then why should the modules pass through=20 the dpdk codebase? Put it in another repo on dpdk.org, advertise it,=20 make testing it as easy as possible and all (like have it integrate with=20 dpdk makefiles if needed) instead. The difference with crypto API and ethtool is different in that the=20 destination for them clearly is dpdk itself. I would like to see=20 experimental code moved to a separate (staging or whatever) directory=20 (or a repo/git submodule) to make the situation absolutely clear. Or a=20 repo/git submodule or such. I also still think experimental features=20 should not be enabled by default in the configs, no other project that I=20 know of does that, but that's another discussion. - Panu -