From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by dpdk.org (Postfix) with ESMTP id 5994C2BB2 for ; Thu, 10 Mar 2016 07:31:17 +0100 (CET) Received: by mail-oi0-f51.google.com with SMTP id d205so54023795oia.0 for ; Wed, 09 Mar 2016 22:31:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=A8lhlgfEK4a3AhQwLVFYc9riE9HAP51GZ4MwXGsn3dU=; b=Nhytz+Nrmt5eFwVri/W7g4qxmhYh2KFFaKhhgDVzeaHwJ67pA/LjIgOeNp+HAsFrHT 41oVujppTIVV6wstEw2eY18TBhsHckmePnAcK+L4udMlxUqV8QYgM2WpS+cnOv3ppkep r/7/9G/j/m3oXig7oXeb6ZgY/w+7lU4ps/bNRb69kqR6sz+wtL8UL+sjVGVdJ+hDgKo2 e1BLyRTDkJjKESVJHBCMcPrWaIv+/CEoXlYuvt91bR3TMhn5mPoIDpDq2YrWS8KMSVgd sc9sUf/TCu4JrZiNBpTIVvjtmO5nhA3C4D06Hg4NXETaKLU98lci2w/W91Dt82q6UZOG FjDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=A8lhlgfEK4a3AhQwLVFYc9riE9HAP51GZ4MwXGsn3dU=; b=Qyuh1eylfpBPRqnV0xu017jnE4oGvvqzpQvIsws8jJbhd+U1YdIu2u1RJ3Ojxru3UH idgRoDdhv/lWE/P9XLsiVLrZW/4azocIqqBH+w66SG0vna5KuHiN16/nIs4/Ee7sTrVY p1OcazAly9joGIVL5n62S0dTLWWLfw80+LT2Kv4j8MKgwE8SclBAHPIuZZ8A2gkO73pA aMooOt+782jFPPgP2KhnNDZr/U82uJMraNCjcJ9EeWReP+UJgQ/TNdlK9c2A7ZU0opTc F9oAJlvML/8RHQWL99zFIPuEvfhcUK0nuvgW5t6+gBCoaAHLknmd9mor8zUMEp6vKQMu atWQ== X-Gm-Message-State: AD7BkJKj5+ILGjxn7vfqe1Tu/o5vd2scXhggbqRoRHwApaFzxs1DgqumGME0olrdMw6hkkS3wg25c4cGxGtCdoaw MIME-Version: 1.0 X-Received: by 10.202.83.129 with SMTP id h123mr994096oib.3.1457591476830; Wed, 09 Mar 2016 22:31:16 -0800 (PST) Received: by 10.60.179.48 with HTTP; Wed, 9 Mar 2016 22:31:16 -0800 (PST) Received: by 10.60.179.48 with HTTP; Wed, 9 Mar 2016 22:31:16 -0800 (PST) In-Reply-To: <4528438.gG6caYbQZH@xps13> References: <1453911849-16562-1-git-send-email-ferruh.yigit@intel.com> <2396478.VfdoPKd37H@xps13> <5360490.85HbqvIh1a@xps13> <4528438.gG6caYbQZH@xps13> Date: Thu, 10 Mar 2016 07:31:16 +0100 Message-ID: From: Vincent JARDIN To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: Avi Kivity , dev@dpdk.org 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, 10 Mar 2016 06:31:17 -0000 Le 10 mars 2016 01:06, "Thomas Monjalon" a =C3=A9crit : > > 2016-03-02 23:35, Thomas Monjalon: > > 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 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 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 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 I do prefer this option. > > - put kcp/kdp in staging and move other experimental libs here > > Any opinion? Are we targetting upstream work without any DPDK staging? > > Please let's make clear the status of these patches.