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

[Ferruh Yigit]

On 3/2/2016 10:18 PM, Jay Rolette wrote:
> 
> On Tue, Mar 1, 2016 at 8:02 PM, Stephen Hemminger
> <stephen at networkplumber.org <mailto:stephen at networkplumber.org>> wrote:
> 
>     On Mon, 29 Feb 2016 08:33:25 -0600
>     Jay Rolette <rolette at infiniteio.com <mailto:rolette at infiniteio.com>>
>     wrote:
> 
>     > On Mon, Feb 29, 2016 at 5:06 AM, Thomas Monjalon
>     <thomas.monjalon at 6wind.com <mailto:thomas.monjalon at 6wind.com>>
>     > wrote:
>     >
>     > > Hi,
>     > > I totally agree with Avi's comments.
>     > > This topic is really important for the future of DPDK.
>     > > So I think we must give some time to continue the discussion
>     > > and have netdev involved in the choices done.
>     > > As a consequence, these series should not be merged in the
>     release 16.04.
>     > > Thanks for continuing the work.
>     > >
>     >
>     > I know you guys are very interested in getting rid of the out-of-tree
>     > drivers, but please do not block incremental improvements to DPDK
>     in the
>     > meantime. Ferruh's patch improves the usability of KNI. Don't
>     throw out
>     > good and useful enhancements just because it isn't where you want
>     to be in
>     > the end.
>     >
>     > 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.
> 
> 
> That's fair. To be clear, it wasn't my intent for code that wasn't baked
> yet to be merged. 
> 
> The main point of my comment was that I think it is important not to
> halt incremental improvements to existing capabilities (KNI in this
> case) just because there are philosophical or directional changes that
> the community would like to make longer-term.
> 
> Bird in the hand vs. two in the bush...
> 

There are two different statements, first, code being not ready, I agree
a fair point (although there is no argument to that statement, it makes
hard to discuss this, I will put aside this), this implies when code is
ready it can go in to repo.

But not having kernel module, independent from their state against what
they are trying to replace is something else. And this won't help on KNI
related problems.

Thanks,
ferruh