Re: [dpdk-dev] [PATCH v6 1/3] kni: rework rte_kni_update_link using ioctl

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 30 Aug 2021 17:27:29 +0300
Igor Ryzhov <iryzhov@nfware.com> wrote:

> Current implementation doesn't allow us to update KNI carrier if the
> interface is not yet UP in kernel. It means that we can't use it in the
> same thread which is processing rte_kni_ops.config_network_if, which is
> very convenient, because it allows us to have correct carrier status
> of the interface right after we enabled it and we don't have to use any
> additional thread to track link status.
> 
> Propagating speed/duplex/autoneg to the kernel module also allows us to
> implement ethtool_ops.get_link_ksettings callback.
> 
> Suggested-by: Dan Gora <dg@adax.com>
> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>

Marking this patch as rejected because KNI is marked as deprecated
and this goes into the "won't fix" category.

The link handling in KNI was always a botch. It violated the kernel
locking (see calling usermode helper with RTNL held); and was fundamentally
flawed. That was one of the reasons KNI never made it upstream
and was marked deprecated.