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

[Thomas Monjalon]

2016-03-03 10:05, 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

What about working with upstream early (step 3 before 2)?
KNI is not so nice but it was advertised and used.
If we want to advertise a replacement, it must be approved by upstream.
We need some stable and widely adopted interfaces to bring more confidence
in the project.