[dpdk-dev] KNI discussion in userspace event

Vincent Jardin vincent.jardin at 6wind.com
Sat Oct 29 01:09:45 CEST 2016



Le 28 octobre 2016 9:23:06 PM Igor Ryzhov <iryzhov at nfware.com> a écrit :

> On Fri, Oct 28, 2016 at 9:40 PM, Thomas Monjalon <thomas.monjalon at 6wind.com>
> wrote:
>
>> 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.
>>
>
> My main point is that if we want to control DPDK ports from Linux, it
> should be done with standard utilities.
> Every standard utility like iproute just uses existing Linux kernel
> interfaces and kernel in its turn uses net_device_ops to control the device.
>
> For example, you want to set MTU of the network device.
> Regardless of the utility you use to do that (even if you write your own),
> there are two options – ioctl or netlink.
> And regardless of the method you choose,  Linux kernel will then call
> "ndo_change_mtu".

DPDK runs on non Linux too (FreeBSD, maybe Windows some days). So we should 
avoid creating such dependencies.

I do like the kind of bifurcated models  (à la RDMA like mlx PMDs) so port 
management is still done using plain OS drivers of the kernel. We should 
rather push toward proper bifurcated drivers:
  - so we decrease maintenance and avoid code duplication
  - we benefit of kernel's interface management

I am not expert of RDMA on FreeBSD and Windows but it seems available.





More information about the dev mailing list