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.