[dpdk-dev] BUG - KNI broken in 4.2 kernel

[dpdk-dev] BUG - KNI broken in 4.2 kernel

[Stephen Hemminger]

The network device ops handles changed again.

Does KNI really need to keep yet another copy of the Intel driver code.
There already are 4 versions:
  1. Out-of tree base driver
  2. In-kernel mainline Linux driver
  3. DPDK driver
  4. KNI DPDK driver

No wonder they can't stay in sync.

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Thomas Monjalon]

2015-08-26 17:15, Stephen Hemminger:
> The network device ops handles changed again.
> 
> Does KNI really need to keep yet another copy of the Intel driver code.
> There already are 4 versions:
>   1. Out-of tree base driver
>   2. In-kernel mainline Linux driver
>   3. DPDK driver
>   4. KNI DPDK driver

You forgot the BSD drivers and probably others.

> No wonder they can't stay in sync.

A patch to remove igb/ixgbe drivers from KNI would be welcome.

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[De Lara Guarch, Pablo]

Hi Thomas, Stephen

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Thursday, August 27, 2015 9:42 AM
> To: Stephen Hemminger
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel
> 
> 2015-08-26 17:15, Stephen Hemminger:
> > The network device ops handles changed again.
> >
> > Does KNI really need to keep yet another copy of the Intel driver code.
> > There already are 4 versions:
> >   1. Out-of tree base driver
> >   2. In-kernel mainline Linux driver
> >   3. DPDK driver
> >   4. KNI DPDK driver
> 
> You forgot the BSD drivers and probably others.
> 
> > No wonder they can't stay in sync.
> 
> A patch to remove igb/ixgbe drivers from KNI would be welcome.

I have a patch ready to submit, I was just waiting for the kernel 4.2 to be released.
I will send the patch anyway, as the kernel is almost stable now (RC8), 
so DPDK will not be broken when kernel is released.

Pablo

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Zhang, Helin]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Wednesday, August 26, 2015 5:15 PM
> To: dev@dpdk.org; Zhang, Helin
> Subject: BUG - KNI broken in 4.2 kernel
> 
> The network device ops handles changed again.
> 
> Does KNI really need to keep yet another copy of the Intel driver code.
Yes, it is a bit ugly. But there is no better way till now, as some of users want to have the functionality of KNI ethtool though limited now.
I have an idea that is to disable KNI ethtool support by default, as most of users may not care about it. Then these users will not be bothered by these type of issues.
For those users who are using KNI ethtool support, they need to fix the issues on any new versions of kernel or similar.
Any good ideas or comments?

Helin

> There already are 4 versions:
>   1. Out-of tree base driver
>   2. In-kernel mainline Linux driver
>   3. DPDK driver
>   4. KNI DPDK driver
> 
> No wonder they can't stay in sync.

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Jay Rolette]

On Thu, Aug 27, 2015 at 10:23 AM, Zhang, Helin <helin.zhang@intel.com>
wrote:
>
>
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Wednesday, August 26, 2015 5:15 PM
> > To: dev@dpdk.org; Zhang, Helin
> > Subject: BUG - KNI broken in 4.2 kernel
> >
> > The network device ops handles changed again.
> >
> > Does KNI really need to keep yet another copy of the Intel driver code.
> Yes, it is a bit ugly. But there is no better way till now, as some of
> users want to have the functionality of KNI ethtool though limited now.
> I have an idea that is to disable KNI ethtool support by default, as most
> of users may not care about it. Then these users will not be bothered by
> these type of issues.
>

Do you know of anyone that uses KNI that doesn't care about it? Since KNI
presents as a normal network interface, it really needs to support the
normal Linux commands (ifconfig, ethtool, ...)

Jay


> For those users who are using KNI ethtool support, they need to fix the
> issues on any new versions of kernel or similar.
> Any good ideas or comments?
>
> Helin
>
> > There already are 4 versions:
> >   1. Out-of tree base driver
> >   2. In-kernel mainline Linux driver
> >   3. DPDK driver
> >   4. KNI DPDK driver
> >
> > No wonder they can't stay in sync.
>

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Zhang, Helin]

From: Jay Rolette [mailto:rolette@infiniteio.com]
Sent: Thursday, August 27, 2015 8:49 AM
To: Zhang, Helin
Cc: Stephen Hemminger; dev@dpdk.org
Subject: Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel


On Thu, Aug 27, 2015 at 10:23 AM, Zhang, Helin <helin.zhang@intel.com<mailto:helin.zhang@intel.com>> wrote:

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org<mailto:stephen@networkplumber.org>]
> Sent: Wednesday, August 26, 2015 5:15 PM
> To: dev@dpdk.org<mailto:dev@dpdk.org>; Zhang, Helin
> Subject: BUG - KNI broken in 4.2 kernel
>
> The network device ops handles changed again.
>
> Does KNI really need to keep yet another copy of the Intel driver code.
Yes, it is a bit ugly. But there is no better way till now, as some of users want to have the functionality of KNI ethtool though limited now.
I have an idea that is to disable KNI ethtool support by default, as most of users may not care about it. Then these users will not be bothered by these type of issues.

Do you know of anyone that uses KNI that doesn't care about it? Since KNI presents as a normal network interface, it really needs to support the normal Linux commands (ifconfig, ethtool, ...)

Based on my experience, only one or two users asked for ethtool support, then we have it. Before that time, we don’t have KNI ethtool support.
I did not mean who uses KNI does not care about it, I mean for those users who don’t use KNI, they shouldn’t be bothered by the KNI compilation issues. That’s why I was thinking if we can disable it by default, but not remove it.

Regards,
Helin

Jay

For those users who are using KNI ethtool support, they need to fix the issues on any new versions of kernel or similar.
Any good ideas or comments?

Helin

> There already are 4 versions:
>   1. Out-of tree base driver
>   2. In-kernel mainline Linux driver
>   3. DPDK driver
>   4. KNI DPDK driver
>
> No wonder they can't stay in sync.

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Stephen Hemminger]

On Thu, 27 Aug 2015 15:56:16 +0000
"Zhang, Helin" <helin.zhang@intel.com> wrote:

> Based on my experience, only one or two users asked for ethtool support, then we have it. Before that time, we don’t have KNI ethtool support.
> I did not mean who uses KNI does not care about it, I mean for those users who don’t use KNI, they shouldn’t be bothered by the KNI compilation issues. That’s why I was thinking if we can disable it by default, but not remove it.
>  
> Regards,
> Helin

Can KNI instead use DPDK hooks to provide generic ethtool semantics.
That way it would work with all hardware.

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Zhang, Helin]

> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Thursday, August 27, 2015 10:46 AM
> To: Zhang, Helin
> Cc: Jay Rolette; dev@dpdk.org
> Subject: Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel
> 
> On Thu, 27 Aug 2015 15:56:16 +0000
> "Zhang, Helin" <helin.zhang@intel.com> wrote:
> 
> > Based on my experience, only one or two users asked for ethtool support, then
> we have it. Before that time, we don’t have KNI ethtool support.
> > I did not mean who uses KNI does not care about it, I mean for those users who
> don’t use KNI, they shouldn’t be bothered by the KNI compilation issues.
> That’s why I was thinking if we can disable it by default, but not remove it.
> >
> > Regards,
> > Helin
> 
> Can KNI instead use DPDK hooks to provide generic ethtool semantics.
> That way it would work with all hardware.
I am not sure if I understood your idea correctly.
My personal point is that the best KNI ethtool support should be processed in user space application.
Sure if we want to support standard Linux ethtool commands, the KNI kernel driver should have a mechanism to work together with user space application. Is that what you said of hooks?
But this may need huge efforts on it.
Sure ideas on ethtool support improvements are always welcome!

Regards,
Helin

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Bruce Richardson]

On Thu, Aug 27, 2015 at 10:45:43AM -0700, Stephen Hemminger wrote:
> On Thu, 27 Aug 2015 15:56:16 +0000
> "Zhang, Helin" <helin.zhang@intel.com> wrote:
> 
> > Based on my experience, only one or two users asked for ethtool support, then we have it. Before that time, we don’t have KNI ethtool support.
> > I did not mean who uses KNI does not care about it, I mean for those users who don’t use KNI, they shouldn’t be bothered by the KNI compilation issues. That’s why I was thinking if we can disable it by default, but not remove it.
> >  
> > Regards,
> > Helin
> 
> Can KNI instead use DPDK hooks to provide generic ethtool semantics.
> That way it would work with all hardware.

Hi Stephen,

by this you mean that it's a generic library/kernel driver that acts as a proxy to make calls
into the ethdev library, rather than driver-specific calls? If so, that's an idea
that should be well worth pursuing. If it's something else you have in mind,
please clarify.

Thanks,

/Bruce

Re: [dpdk-dev] BUG - KNI broken in 4.2 kernel

[Stephen Hemminger]

On Fri, 28 Aug 2015 13:44:28 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:

> On Thu, Aug 27, 2015 at 10:45:43AM -0700, Stephen Hemminger wrote:
> > On Thu, 27 Aug 2015 15:56:16 +0000
> > "Zhang, Helin" <helin.zhang@intel.com> wrote:
> > 
> > > Based on my experience, only one or two users asked for ethtool support, then we have it. Before that time, we don’t have KNI ethtool support.
> > > I did not mean who uses KNI does not care about it, I mean for those users who don’t use KNI, they shouldn’t be bothered by the KNI compilation issues. That’s why I was thinking if we can disable it by default, but not remove it.
> > >  
> > > Regards,
> > > Helin
> > 
> > Can KNI instead use DPDK hooks to provide generic ethtool semantics.
> > That way it would work with all hardware.
> 
> Hi Stephen,
> 
> by this you mean that it's a generic library/kernel driver that acts as a proxy to make calls
> into the ethdev library, rather than driver-specific calls? If so, that's an idea
> that should be well worth pursuing. If it's something else you have in mind,
> please clarify.
> 
> Thanks,
> 
> /Bruce

Yes, not sure exactly how but the other changes to support ethtool like
semantics in DPDK seem to overlap here.