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 12:51:05 +0200 Message-ID: <56D81719.1080500@redhat.com> 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> 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: Ferruh Yigit , 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 5172E2B94 for ; Thu, 3 Mar 2016 11:51:09 +0100 (CET) In-Reply-To: <56D80C75.4000108@intel.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" 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 =C3=A9crit : >>>>>>>> I'd like to see these be merged. >>>>>>>> >>>>>>>> Jay >>>>>>> >>>>>>> The code is really not ready. I am okay with cooperative developm= ent >>>>>>> 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 kerne= l >>>>> 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 ethtoo= l >>> 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 s= tate >>> - 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 modu= le >> 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 throug= h >> 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 wi= th >> 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=20 forward, two steps back. You need to engage upstream NOW, as has been suggested in this thread=20 several times already. - Panu -