2016-10-28 20:29, Igor Ryzhov: > On Fri, Oct 28, 2016 Thomas Monjalon wrote: > > 2016-10-28 15:51, Richardson, Bruce: > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > > 2016-10-28 15:31, Ferruh Yigit: > > > > > * Remove ethtool support ? > > > > > > > > That's the other part of KNI. > > > > It works only for e1000/ixgbe. That's a niche. > > > > > > Yes, it's something we need to remove, but again, we need an > > > alternative first. > > > > > > > > > > > > Still there is some interest, will keep it. But not able to extend it > > > > > to other drivers with current design. > > > > > > > > It should be removed one day. > > > > We must seriously think about a generic alternative. > > > > Either we add DPDK support in ethtool or we create a dpdk-ethtool. > > > > (or at least a library as the one in examples/). > > > > > > I don't view that as a great path forward. Sure, we can do our own > > > ethtool, but then people will look for ifconfig to work, and "ip" to work, > > > etc. I view having a kernel proxy module as the best path here as it is > > > tool agnostic on the userspace side, rather than trying to make every > > > tool for working with kernel netdevs also have support for dpdk ports. > > > > Yes that's the ultimately best solution. > > But: > > - we need some cooperation of the kernel team > > - ethtool manages a device (what DPDK provides) whereas iproute and others > > manage a TCP/IP stack so is out of control of DPDK. > > That's not true. > iproute can control a lot of things like MAC address, promiscuous, MTU, > etc. that cannot be controlled with ethtool. > Just compare net_device_ops and ethtool_ops to see the difference.
Yes you're right. iproute was not a good example :) > And the question is not only about tools, it is also about how Linux kernel > works with network devices. > And it uses net_device_ops, not ethtool_ops. What do you mean exactly? I feel you have something in mind.