[dpdk-dev] [PATCH] doc: announce KNI ethtool removal

[Ferruh Yigit]

On 7/21/2016 5:41 PM, Thomas Monjalon wrote:
> 2016-07-21 16:41, Igor Ryzhov:
>> On Thu, Jul 21, 2016 at 4:33 PM, Ferruh Yigit <ferruh.yigit at 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 at 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

I agree it is not the best design, but this is a functional piece of
code, and as long it keep maintained or completely replaced I am for
keeping it.

> About the point 1, if we decide to keep KNI ethtool, please could you
> duplicate the igb/ixgbe PCI ids in KNI?

Sure, I am not aware of exactly what needs to be done, please show me.

>>> 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?
>