[dpdk-dev] [RFC 0/3] Use common Linux tools to control DPDK ports

Ferruh Yigit ferruh.yigit at intel.com
Thu Feb 4 17:28:41 CET 2016


On Thu, Feb 04, 2016 at 09:40:18AM -0500, Aaron Conole wrote:
> Hi Ferruh,
Hi Aaron,

> 
> I missed your original reply to me. Sorry.
> 
> Ferruh Yigit <ferruh.yigit at intel.com> writes:
> > On Tue, Jan 19, 2016 at 01:29:32PM +0200, Panu Matilainen wrote:
> >> On 01/19/2016 11:59 AM, Ferruh Yigit wrote:
> >>> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote:
> >>>> Ferruh Yigit <ferruh.yigit at intel.com> writes:
> >>>>> This work is to make DPDK ports more visible and to enable using common
> >>>>> Linux tools to configure DPDK ports.
> >>>>
> >>>> This is a good goal. Only question - why use an additional kernel module
> >>>> to do this? Is it _JUST_ for ethtool support?
> >>>
> >>> Kernel module used to create/destroy Linux net_devices, and module has a simple
> >>> driver for that device which only handles control messages by passing them into
> >>> userspace.
> >>>
> >>> To represent DPDK ports as Linux net_devices we need kernel support.
> 
> Why? Just create tun/tap interface, no? Then you get a queue into the
> network stack, as well. Subscribe to netlink, and you can get all of the
> changes that happen in the system - just look for those messages that
> relate to your tun device. At least, that's what I see right away (and I
> have some private patches for this, and you can take them over if you want).
> 
Do you mean subscribe to rtnl messages, like "ip monitor" does?
If so the problem with that is it is unidirectional, from kernel to userspace.

Some operations can be applied with this method, still missing ability return status of action.

But many can't be applied because userspace driver can't send data to kernel,
like almost all ethtool commands requires information from userspace driver.

In kernel side, an entity required to listen and handle userspace driver responses.

> I think most of the stuff you are trying to solve already exists, but I
> am probably misunderstanding something (apologies for that).
> 
> >>>> I think the other stuff
> >>>> can be accomplished using netlink sockets + messages, no?
> >>>
> >>> Netlink sockets just used to communicate kernel-space - user-space, this is not
> >>> why we need a kernel module, for example this communication is implemented in
> >>> original KNI as part of FIFO.
> >>>
> >>>> The only
> >>>> trepidation I would have with something like this is the support from
> >>>> major vendors - out of tree modules are not generally supportable. Might
> >>>> be good to get some of the ethtool commands as netlink messages as well,
> >>>> then it is supportable with no 3rd party kernel modules.
> >>>
> >>> Yes, there is a out of three module problem for some distros, but unfortunately
> >>> we are not able to find a solution for this case without an
> >>> external kernel module.
> >>>
> >>> This patch is still an RFC and if we receive suggested solution without a kernel
> >>> module, we can work on it together.
> >>
> >> If it has to be in the kernel then you need to find a design that is 
> >> upstreamable. Out of tree kernel modules are not a solution, they're a 
> >> problem that people are working on eliminating.
> >>
> >
> > Hi Stephen, and other Linux experts in the mail list,
> >
> > Can you please help finding a upstreamable solution for kernel control path?
> >
> > Mainly what we are looking for is userspace network driver support in
> > kernel, similar to what FUSE does but a much simple version.
> >
> > Above KCP module basically does this, by having a network driver which
> > passing requests to userspace network driver, but it is not generic
> > enough.
> >
> > I wonder if it is possible make it more generic by extending rtnetlink support:
> > 1- Add a new network driver to Linux (or update existing one like tun)
> > to forward requests, get responses.
> > 2- Extend rtnelink to support to attach any userspace driver to this
> > device? (ip link set <device> uspace <?> ?)
> >
> > Does this make sense?
> >
> > rtnetlink already supports creating interfaces, and it provides
> > kernel/user space communication,
> > with "attach" support interface learns about it's peer in usersppace
> > and can communicate.
> >
> > FUSE like communication method also can be alternative to transfer
> > request and responses, but since rtnelink support exists, no need to
> > create something new think.
> >
> > Thanks,
> > ferruh


More information about the dev mailing list