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. > > 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!
