On 12/1/2018 11:12 AM, Igor Ryzhov wrote: > 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.
I tried to clarify this in the patch, but it doesn't enable ethtool_ops for 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. You should go to userspace to get device information, right. Since now userspace has the driver. So a channel between kernel and userspace is required. Please share your plans/design on this support. > > 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. >>
