From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 98B721C52 for ; Thu, 3 Mar 2016 11:12:50 +0100 (CET) Received: by mail-wm0-f47.google.com with SMTP id p65so27331203wmp.1 for ; Thu, 03 Mar 2016 02:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=8bxWRZuUYxStIirkHfDy40uUo4fD/MSdaDY+sza6Zog=; b=kisbz+hboxdQwi6dM5tI0e7gfsT/Df+khDoibxrWaBeoXF4ilOqV9sZKDZ3YNWznmc 7gcbTcToH+baXM/A5BzlatkBkgcZsIoEzUphv8zdQaztMA0tIAtlnYGauyThReVcy8tq SN+Yq2qJ53OpnFfpvhGOSedCiLli4o+SR1XhnksIVkoxKmhxdm/k1NT67dfu7vBJniIl Naywq7fTc/DvPjR4R8xHVYNOgIZ441sGHaITscjNRCqwteh0tgivDgTP08SNr+Myb0bO ODJEzmCLOnumcS2NQyK4nYNW1h6/SHMsITjvHoTLVOz99TIdtOgdVq2lgiKxOF7Meeul XvOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=8bxWRZuUYxStIirkHfDy40uUo4fD/MSdaDY+sza6Zog=; b=IcwobTXhCB/bwcd4GlDOPrtS3Rx/0Qu2aZMSVoV38jmSCZtNyw11Rd6T1ztHujvJft B6ji9KvFPePzi3C7wOsZR6V0w5xi7fBogNc3E/giiX034+Bi11/bcI5hqN4ds79upH26 XOiSD6iosb8lM44lpdMd94f7Je7/lapMi771LLuuQc31rV1RSIqUIu4MuQeBVUVpd68T 6tzIarObcPyuxJrUS71J3R2tJc9JvFPFd+73PgfKLp3auOAoIXNx0vuhMcb05PFmnZwh Kz+5+EBvXjkbaMCObbxtFiTp8NOscl5o9xngKSSeOX+6UL48KwZOoiRsOFgWrhyB3etR MujQ== X-Gm-Message-State: AD7BkJKOzTYAmM/G79QBvC6uKDGdaUjtn97k5tHUGfW9ubQbCSVaq9GUKj4extDaHNejVGS7 X-Received: by 10.194.21.197 with SMTP id x5mr1063181wje.90.1456999970448; Thu, 03 Mar 2016 02:12:50 -0800 (PST) Received: from xps13.localnet (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id da6sm30433059wjb.24.2016.03.03.02.12.49 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 02:12:49 -0800 (PST) From: Thomas Monjalon To: Ferruh Yigit Date: Thu, 03 Mar 2016 11:11:14 +0100 Message-ID: <1573647.RqL1XjPqdZ@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56D80C75.4000108@intel.com> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <56D7F65C.7020501@redhat.com> <56D80C75.4000108@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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:12:50 -0000 2016-03-03 10:05, Ferruh Yigit: > 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 =E9crit : > >>>>>>> I'd like to see these be merged. > >>>>>>> > >>>>>>> Jay > >>>>>> > >>>>>> The code is really not ready. I am okay with cooperative devel= opment > >>>>>> 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 wh= en it > >>>>>> gets rebuilt/reworked/scrapped. > >>>>>> > >>>>> > >>>>> Exactly. > >>>> > >>>> +1 too > >>>> > >>>> We need to build on this innovation while there is a path for ke= rnel > >>>> 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 t= he > >>> kernel > >>> community. > >>> > >>> The kernel modules must clearly target an upstream integration. > >> > >> Actually the examples directory has been used as a staging for eth= tool > >> 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= > >=20 > > To answer this, I think we need to start by clarifying the kernel m= odule > > situation. Quoting your from > > http://dpdk.org/ml/archives/dev/2016-January/032263.html: > >=20 > >> 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. > >=20 > > This to me reads "no more out-of-tree kernel modules, period" but h= ere > > we are discussing the fate of another one. > >=20 > > If the policy truly is "no more kernel modules" (which I would full= y > > back and applaud) then I think there's little to discuss - if the > > destination is kernel upstream then why should the modules pass thr= ough > > 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. > >=20 > Hi Panu, >=20 > 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. >=20 > I believe replacing KNI module with new code in DPDK is a required > improvement step. But to replace, KNI users should verify the new cod= es. >=20 > Going directly from KNI to Linux upstream, if possible, is not easy. > Upstreaming should be done in incremental steps. >=20 > 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 What about working with upstream early (step 3 before 2)? KNI is not so nice but it was advertised and used. If we want to advertise a replacement, it must be approved by upstream.= We need some stable and widely adopted interfaces to bring more confide= nce in the project.