20/07/2020 06:50, Hemant Agrawal: > HI Thomas, > > From: Thomas Monjalon <tho...@monjalon.net> > 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 <sachin.sax...@nxp.com> > > > Signed-off-by: Hemant Agrawal <hemant.agra...@nxp.com> > > 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.