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 233435588 for ; Wed, 16 Mar 2016 16:03:57 +0100 (CET) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 658EAC00F5FB; Wed, 16 Mar 2016 15:03:56 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-187.ams2.redhat.com [10.36.6.187]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2GF3sS4014431; Wed, 16 Mar 2016 11:03:54 -0400 To: Thomas Monjalon References: <1455858349-14639-1-git-send-email-ferruh.yigit@intel.com> <56E934E5.4080905@intel.com> <56E95C6B.1000004@redhat.com> <11855450.AeS7qhTG6k@xps13> Cc: Ferruh Yigit , dev@dpdk.org, David Marchand , Helin Zhang From: Panu Matilainen Message-ID: <56E975DA.8030300@redhat.com> Date: Wed, 16 Mar 2016 17:03:54 +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: <11855450.AeS7qhTG6k@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Subject: Re: [dpdk-dev] [PATCH v3 0/2] slow data path communication between DPDK port and Linux 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: Wed, 16 Mar 2016 15:03:57 -0000 On 03/16/2016 03:58 PM, Thomas Monjalon wrote: > 2016-03-16 15:15, Panu Matilainen: >> What I really would like to see is a clear policy regarding kernel >> modules in DPDK. I certainly am in no position to dictate one, and >> that's why I've been asking questions and throwing around crazy (or not) >> ideas around the topic. > > I think the consensus is to avoid new kernel module, > but allow them in a staging directory while being discussed upstream. To me the more interesting question is: what happens after that? As in, if upstream says no, does it mean axe from dpdk, no ifs and buts? If accepted upstream, does a version of the module still live within dpdk codebase (for example to provide the version for older kernel versions, I dont see that as unreasonable at all)? > About the existing out-of-tree kernel modules, we must continue trying > to obsolete them with upstream work. Agreed. > > If you feel the consensus must be clearly stated and acked, > please send a patch for doc/guides/contributing/design.rst. I'll be happy to, once we have a clear consensus on what the policy actually is. - Panu -