From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Igor Ryzhov <iryzhov@nfware.com>, Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc: announce KNI ethtool removal
Date: Thu, 21 Jul 2016 18:41:44 +0200 [thread overview]
Message-ID: <1531021.TGlYe7obp8@xps13> (raw)
In-Reply-To: <CAF+s_Fw3fb+gYsBpteE_P149E5xyq0FMQuWoH-DKpVvykydBOQ@mail.gmail.com>
2016-07-21 16:41, Igor Ryzhov:
> On Thu, Jul 21, 2016 at 4:33 PM, Ferruh Yigit <ferruh.yigit@intel.com>
> wrote:
> > On 7/20/2016 5:07 PM, Thomas Monjalon wrote:
> > > The out-of-tree kernel code must be avoided.
> > > Moreover there is no good reason to keep this legacy feature
> > > which is only partially supported.
> > >
> > > As described earlier in this plan:
> > > http://dpdk.org/ml/archives/dev/2016-July/043606.html
> > > it will help to keep PCI ids in PMD code.
> > >
> > > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
[...]
> > > +
> > > +* The ethtool support will be removed from KNI in 16.11.
> > > + It is implemented only for igb and ixgbe.
> > > + It is really hard to maintain because it requires some out-of-tree kernel
> > > + code to be duplicated in this kernel module.
> > > + Removing this partial support will help to restrict the PCI id definitions
> > > + to the PMD code.
> >
> > KNI ethtool is functional and maintained, and it may have users!
> >
> > Why just removing it, specially without providing an alternative?
Because
1/ It is using the shared PCI ids that we want to move
2/ It has a poor support (igb/ixgbe) and makes users confused
3/ It is a big import of another version of igb/ixgbe drivers
About the point 1, if we decide to keep KNI ethtool, please could you
duplicate the igb/ixgbe PCI ids in KNI?
> > Is is good time to discuss KCP again?
>
> I think good alternative is rte_ethtool library from ethtool sample
> application.
Yes I think so.
> But I am wondering why this code is only in app, not in lib.
It is an example lib because we were not sure wether we wanted to
support it. But maybe it is time to discuss its status and check
if it can be integrated with other DPDK libs?
next prev parent reply other threads:[~2016-07-21 16:41 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-20 16:07 Thomas Monjalon
2016-07-21 15:33 ` Ferruh Yigit
2016-07-21 15:41 ` Igor Ryzhov
2016-07-21 16:41 ` Thomas Monjalon [this message]
2016-07-26 13:23 ` Ferruh Yigit
2016-07-26 13:42 ` Thomas Monjalon
2016-07-21 18:20 ` Jay Rolette
2016-07-21 20:32 ` Thomas Monjalon
2016-07-21 20:54 ` Jay Rolette
2016-07-21 23:15 ` Thomas Monjalon
2016-07-22 17:20 ` Andriy Berestovskyy
2016-07-26 13:18 ` Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1531021.TGlYe7obp8@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=iryzhov@nfware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).