> -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Friday, October 28, 2016 4:13 PM > To: Yigit, Ferruh <ferruh.yigit at intel.com> > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] KNI discussion in userspace event > > 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. > 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. > > > *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. /Bruce
