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

[Andriy Berestovskyy]

Hi folks,
Just to clarify. Thomas is talking about removing just the KNI ethtool
(i.e. lib/librte_eal/linuxapp/kni/ethtool/*). The major functionality
of those 45K lines of code is to get the same MAC address on the KNI
interface and the underlying igb/ixgbe NIC.

At the moment the rest of the DPDK eth devices work fine without the
KNI ethtool. The workaround is very simple: use ifconfig or ip tool to
set the same MAC you have on your NIC. Put it into your network
configuration to make it permanent.

Examples:
ifconfig vEth0_0 hw ether <your NIC's MAC>
or
ip link set vEth0_0 address <your NIC's MAC>
or
in /etc/network/interfaces under the "iface vEth0_0" section add the following:
    hwaddress <your NIC's MAC>


Andriy

On Thu, Jul 21, 2016 at 10:54 PM, Jay Rolette <rolette at infinite.io> wrote:
> On Thu, Jul 21, 2016 at 3:32 PM, Thomas Monjalon <thomas.monjalon at 6wind.com>
> wrote:
>
>> 2016-07-21 13:20, Jay Rolette:
>> > On Thu, Jul 21, 2016 at 10:33 AM, Ferruh Yigit <ferruh.yigit at intel.com>
>> > wrote:
>> > > KNI ethtool is functional and maintained, and it may have users!
>> > >
>> > > Why just removing it, specially without providing an alternative?
>> > > Is is good time to discuss KCP again?
>> >
>> > Yes, my product uses it.
>>
>> Your product uses what? KCP? KNI? KNI ethtool?
>>
>
> Sorry, that wasn't very clear. It uses KNI + ifconfig to configure the
> device/interface in Linux. I'm assuming the "ethtool" bits under discussion
> are the same things that make ifconfig work with KNI to the limited extent
> it does.
>
>> Seems like we are back to the same discussion we
>> > had a few months ago about the KNI situation...
>> >
>> > It shouldn't be removed unless there is a replacement, ideally one that
>> > works with the normal Linux tools like every other network device.
>>
>> This ethtool module works only for igb and ixgbe!
>> There is already no replacement for other drivers.
>> Who works on a replacement?
>>
>
> Ferruh submitted KCP previously, but you guys didn't like the fact that it
> was a kernel module. IIRC, one of the gains from that was simplified
> maintenance because you didn't need driver specific support for KNI.
> Assuming he's still willing to beat it into shape, we have something that
> is already most of the way there.
>
> If people are going to continue to block it because it is a kernel module,
> then IMO, it's better to leave the existing support on igx / ixgbe in place
> instead of stepping backwards to zero support for ethtool.
>
>> While the code wasn't ready at the time, it was a definite improvement
>> over what
>> > we have with KNI today.
>>



-- 
Andriy Berestovskyy