[dpdk-dev] [PATCH v3 1/8] net/dpaa: add support for fmlib in dpdk

Hemant Agrawal hemant.agrawal at nxp.com
Tue Jul 21 05:26:16 CEST 2020


Hi Thomas,

On 20-Jul-20 10:36 PM, Thomas Monjalon wrote:
> 20/07/2020 06:50, Hemant Agrawal:
>> HI Thomas,
>>
>> From: Thomas Monjalon <thomas at 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.saxena at nxp.com>
>>>> Signed-off-by: Hemant Agrawal <hemant.agrawal at 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.

<HEMANT> KNI is for DPDK specific stuff. But many times base codes are already part of kernel tree or some other OS and same codebase can go to Userspace tree as well. So, they have dual licenses. 

>
>>> 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.

<HEMANT> The original code was for non-linux powerpc platforms. My problem was that the base team still do fixes in that code base.
If I change the majority of the code, I may not be able to sync the fixes in future. 

>
>>> 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.
>
>
<HEMANT> Actually we sent this patchset originally on 27 May.  That was well within new feature date, so I did not sent explicit roadmap. If that helps you, we will try doing it. 



More information about the dev mailing list