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 5172E2B94 for ; Thu, 3 Mar 2016 11:51:09 +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 7239785541; Thu, 3 Mar 2016 10:51:08 +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 u23Ap6fA010137; Thu, 3 Mar 2016 05:51:07 -0500 To: Ferruh Yigit , 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> <56D7F65C.7020501@redhat.com> <56D80C75.4000108@intel.com> From: Panu Matilainen Message-ID: <56D81719.1080500@redhat.com> Date: Thu, 3 Mar 2016 12:51:05 +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: <56D80C75.4000108@intel.com> 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 10:51:09 -0000 On 03/03/2016 12:05 PM, Ferruh Yigit wrote: > On 3/3/2016 8:31 AM, Panu Matilainen wrote: >> 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. >> > Hi Panu, > > I just want to remind that these modules are to replace existing KNI > kernel module, and to reduce it's maintenance cost. > We are not adding new kernel modules for new features. > > I believe replacing KNI module with new code in DPDK is a required > improvement step. But to replace, KNI users should verify the new codes. > > Going directly from KNI to Linux upstream, if possible, is not easy. > Upstreaming should be done in incremental steps. > > How about following steps: > 1- Add KCP/KDP with an EXPERIMENTAL flag. > 2- When they are mature enough, remove KNI, remove EXPERIMENTAL from > KCP/KDP. > 3- Work on upstreaming And if upstream says no, as they just as well might? You're one step forward, two steps back. You need to engage upstream NOW, as has been suggested in this thread several times already. - Panu -