[dpdk-dev] [PATCH 1/3] kcp: add kernel control path kernel module
Stephen Hemminger
stephen at networkplumber.org
Thu Mar 3 17:59:15 CET 2016
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.
More information about the dev
mailing list