On Fri, Oct 28, 2016 at 7:13 PM, Thomas Monjalon <thomas.monjalon at 6wind.com> 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: > > > > * virtio-user + vhost-net > > > > This can be valid alternative, removes the out of tree kernel module > > > > need. But missing control path. Proof of concept work will be done. > > > > > > That's probably a smart alternative for packet injection. > > > What do you mean exactly by "missing control path"? > > > > We'll have to see how it performs - which is the key gap for data path > that KNI fills. Until we get an alternative with (nearly) equivalent > performance, there will be demand for KNI to stick around. > > The "control path" is the ethtool part, to get stats and do operations > on the NIC using command-line tools. > > > > > > > > > * 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. 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. > > > > Or we do nothing and wait to have more hardware like Mellanox > supporting a > > > kernel bifurcated driver approach. > > > > Given the lack of other NICs supporting that, I think it could be quite > a wait! Also, it doesn't work for virtio ports, for pcap ports, or any > other ports which don't have physical hardware backing them. No reason you > shouldn't be able to pull stats from all your dpdk ethdevs, not just the > ones with physical hardware. The same ethdev APIs work for them, so should > the same tools. > > Yes, very good point. > > > > > *KNI PMD > > > > Patch is in the mail list, missing comments. If it gets some > > > > interest/comments/acks it may go in to next release. > > > > > > I'm not against KNI PMD but it looks strange to add more support to an > old > > > dying approach. > > > > I think the main idea here is to clean up the API - at least for the > data path. There is no reason why we need special KNI RX/TX functions, when > ethdev RX/TX functions could do the job. However, at a higher level, the > more basic requirement is that whatever solution for the data-path to > kernel from dpdk is, it needs to appear as an ethdev, and not as a special > library with different APIs, as KNI is now. > > Yes I agree to unifiy (and reduce) API. > Why this PMD is not more commented? > KNI users should be interested to review it. > Please dear community, we need more reviews! >
