Hi Stephen, I also do not see the point of the current implementation of ethtool support. That's why I sent this patch – it enables ethtool_ops for all devices, independent of the underlying driver. Right now only .get_link is supported, but I am thinking about implementation of a larger set of functions, using req/resp queue, like netdev_ops functions are working.
Regarding the KNI itself, we use it as Linux mirror of physical port for: 1. Port configuration from Linux – such functions as set_mac, change_mtu, etc. And ethtool_ops will be used the same way. 2. Passing control-plane packets to Linux. Can virtio user be used the same way, as a mirror of physical port? Best regards, Igor On Sat, Dec 1, 2018 at 2:38 AM Stephen Hemminger <step...@networkplumber.org> wrote: > On Fri, 30 Nov 2018 22:47:50 +0300 > Igor Ryzhov <iryz...@nfware.com> wrote: > > > Current implementation of kni_ethtool_ops just uses corresponding > > ethtool_ops function of underlying driver for all functions except for > > .get_link. This commit sets kni->net_dev->ethtool_ops directly to the > > ethtool_ops of the corresponding driver. > > > > For unknown drivers (all but ixgbe and i40e) we still use > > kni_ethtool_ops with implemented .get_link function. > > > > Signed-off-by: Igor Ryzhov <iryz...@nfware.com> > > Why does KNI still support ethtool which: > 1. Only works on a subset of devices > 2. Requires a 3rd implmentation of the HW device (Linux, DPDK, and KNI) > > Then again why does KNI exist at all? What is missing from virtio user > which > is faster anyway. >
