From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7CABCA0527; Mon, 20 Jul 2020 19:06:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A2E561BFBF; Mon, 20 Jul 2020 19:06:06 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id BBA071BFBA; Mon, 20 Jul 2020 19:06:04 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 612F75C0209; Mon, 20 Jul 2020 13:06:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 20 Jul 2020 13:06:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= gEdhzEzNcCaQU6Nq7JjP5PUlYeRj2NChi7jtUA/XtEE=; b=CIFQOBCk68YPM2L+ cEUYyMC0SVvfb2MaR1XqnFz3jqNAAwISHOy1JczWvuesKEY6PAXuICoUl7GxDhhg R5gVM2FfzgXGR8rbYSb5qwag2UZAV3Q4XVdlxUjuQo0Fw3hzQQ40se0lMFwxvFb4 oTjWxustChAZsd53oQ0jeTTRENlOarxxTOAfp7dChUjSCeQVJCcrxPSjObcSU14f C5HMoiJ38ocgjSNQJ++8RMer+GTU+t4ukYRh7Pxwh78S6EkduSkmh9BrlSTXJtVd vyR0UtFe1LzsEmrlZQ2j6L76R9i5Y3dNl9b9CkNt3ENf94MgyKJ65ZjxiCBwsLVA 8VUwfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=gEdhzEzNcCaQU6Nq7JjP5PUlYeRj2NChi7jtUA/Xt EE=; b=dtTF6M4/peGgp7vMqyriD2Lu+HLkS8SuxPcZ+vSzDpYdoWYLHvswJBpsQ OEkZxMvtn7dr+X6J+Oue8MnDWFJ1Sw0wpoCQRX2psk/OE/fOJvXv6T8C/4VsOHtp wG7bv0OD1ujp1P5xCo17o5hSsIq1vuEAnRYgLC2+r2U4pNjLIkcjs88Cw/3nrhqs DekcMbZVbgG5kKIL7viRX9n2o1hr7rvK4OhrX/nAJIn3Cm2A+hplwXhHpaf+bZ7l 8IYIQlITT4/eZoIcwZ053eKeDCmrRYhKlStijVGeENqlZ9MpQVXnPpmuEe2nHxP0 VqwO7FzBzzToHrb/O2F1ut//8cAIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgeeggdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpeffvdffjeeuteelfeeileduudeugfetjeelveefkeejfeeigeehteff vdekfeegudenucffohhmrghinhepughpughkrdhorhhgnecukfhppeejjedrudefgedrvd dtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id DE7F0328005D; Mon, 20 Jul 2020 13:06:02 -0400 (EDT) From: Thomas Monjalon To: Sachin Saxena , Hemant Agrawal Cc: "dev@dpdk.org" , Ferruh Yigit , "techboard@dpdk.org" Date: Mon, 20 Jul 2020 19:06:01 +0200 Message-ID: <5337642.iclhRcez8O@thomas> In-Reply-To: References: <20200710171946.23246-1-hemant.agrawal@nxp.com> <11996214.pnvohz1kia@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/8] net/dpaa: add support for fmlib in dpdk X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 20/07/2020 06:50, Hemant Agrawal: > HI Thomas, > > From: Thomas Monjalon > 17/07/2020 13:36, Ferruh Yigit: > > On 7/11/2020 9:17 AM, Hemant Agrawal wrote: > > > DPAA platorm MAC interface is known as FMAN i.e. Frame Manager. > > > There are two ways to control it. > > > 1. Statically configure the queues and classification rules before > > > the start of the application using FMC tool. > > > 2. Dynamically configure it within application by making API calls > > > of fmlib. > > > > > > The fmlib or Frame Manager library provides an API on top of the > > > Frame Manager driver ioctl calls, that provides a user space > > > application with a simple way to configure driver parameters and PCD > > > (parse - classify - distribute) rules. > > > > > > This patch integrates the base fmlib so that various queue config, > > > RSS and classification related features can be supported on DPAA platform. > > > > > > This base fmlib is shared across multiple project. > > > - it is not following block comments style for doxygen and other > > > comments. > > > - it usages camel case for naming. > > > - it is not following the 80 char limits in code > > > > > > Signed-off-by: Sachin Saxena > > > Signed-off-by: Hemant Agrawal > > Series applied to dpdk-next-net/master, thanks. > > >Sorry, this time I don't agree with Ferruh's decision of merging this series. > > >Checkpatch is sending too many warnings. > > [Hemant] The base codes, which are coming from common area was not originally meant for Linux. > If we change the original starting code of it, the the maintenance become very painful otherwise. > > >But most importantly, the licensing has not been agreed in techboard and govboard. > > [Hemant] you are wrong here. Which license difference are you talking about? Standard licenses do not need techboard and govboard approval. > /* SPDX-License-Identifier: (BSD-3-Clause OR GPL-2.0) is the approved license. It have been used in DPDK since long. > DPDK exception file states: > Note that following licenses are not exceptions:- > - BSD-3-Clause > - Dual BSD-3-Clause OR GPL-2.0 > - Dual BSD-3-Clause OR LGPL-2.1 > - GPL-2.0 (*Only for kernel code*) > Any base code which is shared among kernel and Userspace space - mostly likely will have this kind dual license only. > Note: you don't add "Dual" word while stating SPDX string - it is implicit. Indeed you're right it is not marked as an exception in license/exceptions.txt. This is a discrepancy with the charter: https://www.dpdk.org/charter/ In section 6.i.iii: " A disjunctive licence choice of BSD-3-Clause OR GPL-2.0 or BSD-3-Clause OR LGPL-2.1 will be used for code that is shared between the kernel and userspace. " But we are not building a kernel module with this code, as it is the case for KNI. > > Why dropping this codebase in DPDK instead of pulling it as a dependency? > > I don't like seeing DPDK becoming a pile of code duplicated from somewhere else. > [Hemant] We are not using the library as it is and making some serious changes in the generic library to suit the DPDK use-case. > So, it is not possible for us to use the *original* code of fmlib, which is public. I don't understand. Either you don't change the code, so you use the original one as a dependency, or you change the code for DPDK use, so you can adapt it to DPDK. > > I will drop this series from 20.08, waiting for a clear consensus. > [Hemant] Why? > [Hemant] >Note: I don't remember having heard about such change before, especially not in the roadmap. > [Hemant] So anyone not publishing a roadmap - you will not accept features? This is just a note explaining why I discover it so late.