[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module

[Ferruh Yigit]

On 3/3/2016 8:31 AM, Panu Matilainen wrote:
> On 03/03/2016 12:35 AM, Thomas Monjalon wrote:
>> 2016-03-02 12:21, Thomas Monjalon:
>>> 2016-03-02 11:47, Vincent JARDIN:
>>>> Le 02/03/2016 09:27, Panu Matilainen a écrit :
>>>>>>> I'd like to see these be merged.
>>>>>>>
>>>>>>> Jay
>>>>>>
>>>>>> The code is really not ready. I am okay with cooperative development
>>>>>> but the current code needs to go into a staging type tree.
>>>>>> No compatibility, no ABI guarantees, more of an RFC.
>>>>>> Don't want vendors building products with it then screaming when it
>>>>>> gets rebuilt/reworked/scrapped.
>>>>>>
>>>>>
>>>>> Exactly.
>>>>
>>>> +1 too
>>>>
>>>> We need to build on this innovation while there is a path for kernel
>>>> mainstream. The logic of using a staging is a good one.
>>>>
>>>> Thomas,
>>>>
>>>> can we open a staging folder into the DPDK like it is done into the
>>>> kernel?
>>>
>>> It's possible to create a staging directory if everybody agree.
>>> It is important to state in a README file or in the doc/ that
>>> there will be no guarantee (no stable ABI, no validation and can be
>>> dropped)
>>> and that it is a work in progress, a suggestion to discuss with the
>>> kernel
>>> community.
>>>
>>> The kernel modules must clearly target an upstream integration.
>>
>> Actually the examples directory has been used as a staging for ethtool
>> and
>> lthread. We also have the crypto API which is still experimental.
>> So I think we must decide among these 3 solutions:
>>     - no special directory, just mark and document an experimental state
>>     - put only kcp/kdp in the staging directory
>>     - put kcp/kdp in staging and move other experimental libs here
> 
> To answer this, I think we need to start by clarifying the kernel module
> situation. Quoting your from
> http://dpdk.org/ml/archives/dev/2016-January/032263.html:
> 
>> Sorry the kernel module party is over.
>> One day, igb_uio will be removed.
>> I suggest to make a first version without interrupt support
>> and work with Linux community to fix your issues.
> 
> This to me reads "no more out-of-tree kernel modules, period" but here
> we are discussing the fate of another one.
> 
> If the policy truly is "no more kernel modules" (which I would fully
> back and applaud) then I think there's little to discuss - if the
> destination is kernel upstream then why should the modules pass through
> the dpdk codebase? Put it in another repo on dpdk.org, advertise it,
> make testing it as easy as possible and all (like have it integrate with
> dpdk makefiles if needed) instead.
> 
Hi Panu,

I just want to remind that these modules are to replace existing KNI
kernel module, and to reduce it's maintenance cost.
We are not adding new kernel modules for new features.

I believe replacing KNI module with new code in DPDK is a required
improvement step. But to replace, KNI users should verify the new codes.

Going directly from KNI to Linux upstream, if possible, is not easy.
Upstreaming should be done in incremental steps.

How about following steps:
1- Add KCP/KDP with an EXPERIMENTAL flag.
2- When they are mature enough, remove KNI, remove EXPERIMENTAL from
KCP/KDP.
3- Work on upstreaming

Thanks,
ferruh

> The difference with crypto API and ethtool is different in that the
> destination for them clearly is dpdk itself. I would like to see
> experimental code moved to a separate (staging or whatever) directory
> (or a repo/git submodule) to make the situation absolutely clear. Or a
> repo/git submodule or such. I also still think experimental features
> should not be enabled by default in the configs, no other project that I
> know of does that, but that's another discussion.
> 
>     - Panu -