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

[Ferruh Yigit]

On 3/3/2016 4:59 PM, Stephen Hemminger wrote:
> On Thu, 3 Mar 2016 10:11:57 +0000
> Ferruh Yigit <ferruh.yigit at intel.com> wrote:
> 
>> 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
>>
> 
> Why not re-submit patches but put in lib/librte_eal/staging or similar path
> and make sure that it does not get build by normal build process.
> 
I will do when staging is ready/defined.

Also will start working on upstreaming modules.

Thanks,
ferruh