From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by dpdk.org (Postfix) with ESMTP id D39682BB4 for ; Wed, 16 Mar 2016 16:16:51 +0100 (CET) Received: by mail-wm0-f48.google.com with SMTP id l68so195028755wml.0 for ; Wed, 16 Mar 2016 08:16:51 -0700 (PDT) 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=Pdmjgu8dQul2X1WvzYR54fJ/lvfrBxyoGrZsPFJ4gDY=; b=AnmoWkkdg6TZkMB+LcjlH1NwJe/MKs288ys5NQTz9EoLVUUF+cNwaI8tPSCC6scNAQ 59boQkhMwGw9mXiXc5U7e/mrrHx+xAMNYj0pNjssOA4EijlhMgdcusyxzYW4QG3eTNJU zRSI62+sYTVHWPRyihd99wHGZsP9UY5SBQ2YjSoFMzbXYDsuoG5hHaD+kxeGqEakwlRy 4lXmVdFRapbqeRxs4tbfm+7wlp4VJ0zK5INWfcdp9Vr1OYrM5z5THl7ECukUwl+vuecI yqiBlCCFH7UIcTz/IGEi8aPDAJkd0jjSjBdZyNGlCFUVjzRf/9ijLSL8UUScOQDMVvnb yfzg== 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=Pdmjgu8dQul2X1WvzYR54fJ/lvfrBxyoGrZsPFJ4gDY=; b=jMFDuabvsbXJV2hdpZTW9YFgMXKoX6ZmMbkGqPwryMHirgkd3GctwNZlaPEVWq3cCR EUjGsoUGkor03i2I59gkrtheGEsyT9xf2RaTU7VlX+UM2/gMvSlzd0vlYpB6s//al1Sj hgekiRyJ3YZoNsAM4c9Xa/PdlWqz5+edTfXy3NSZCTK6gofqQFEiy/CDecx5P1W2mcAl OG8m/J72j5ir/AstfvRm6nPedycJdqn29kSs9U8et1RyG3tWwf4o26H7XPrj8e99raYZ SvLu9awfgD7xF2rJb/Ktdpz3xTNolXtZFkEh5Y8xxPjIFXp404erjiQkQv5qyJsp13HZ AMGg== X-Gm-Message-State: AD7BkJJdkUC1McnkkBtCbHhf2bukeCuhFgseRH0x13bpp0qpjyDwLz5T/KR44fj8sMXKugMk X-Received: by 10.28.104.131 with SMTP id d125mr28591597wmc.99.1458141411687; Wed, 16 Mar 2016 08:16:51 -0700 (PDT) Received: from xps13.localnet (91.111.75.86.rev.sfr.net. [86.75.111.91]) by smtp.gmail.com with ESMTPSA id h7sm25915080wmf.9.2016.03.16.08.16.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 08:16:51 -0700 (PDT) From: Thomas Monjalon To: Panu Matilainen Cc: Ferruh Yigit , dev@dpdk.org, David Marchand , Helin Zhang Date: Wed, 16 Mar 2016 16:15:24 +0100 Message-ID: <1909241.8RRZd4veSo@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <56E975DA.8030300@redhat.com> References: <1455858349-14639-1-git-send-email-ferruh.yigit@intel.com> <11855450.AeS7qhTG6k@xps13> <56E975DA.8030300@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:16:52 -0000 2016-03-16 17:03, Panu Matilainen: > 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. Sending a patch is the most efficient way of having the discussion happens with more contributors. We, as a technical community, take some patch-based decisions ;)