[dpdk-dev] [PATCH 0/4] Introduce IF proxy library

Stephen Hemminger stephen at networkplumber.org
Thu Apr 16 19:04:33 CEST 2020


On Thu, 16 Apr 2020 22:19:05 +0530
Jerin Jacob <jerinjacobk at gmail.com> wrote:

> On Thu, Apr 16, 2020 at 9:41 PM Stephen Hemminger
> <stephen at networkplumber.org> wrote:
> >
> > On Fri, 6 Mar 2020 17:41:00 +0100
> > Andrzej Ostruszka <aostruszka at marvell.com> wrote:
> >  
> > > What is this useful for
> > > =======================
> > >
> > > Usually, when an ethernet port is assigned to DPDK it vanishes from the
> > > system and user looses ability to control it via normal configuration
> > > utilities (e.g. those from iproute2 package).  Moreover by default DPDK
> > > application is not aware of the network configuration of the system.
> > >
> > > To address both of these issues application needs to:
> > > - add some command line interface (or other mechanism) allowing for
> > >   control of the port and its configuration
> > > - query the status of network configuration and monitor its changes
> > >
> > > The purpose of this library is to help with both of these tasks (as long
> > > as they remain in domain of configuration available to the system).  In
> > > other words, if DPDK application has some special needs, that cannot be
> > > addressed by the normal system configuration utilities, then they need
> > > to be solved by the application itself.
> > >
> > > The connection between DPDK and system is based on the existence of
> > > ports that are visible to both DPDK and system (like Tap, KNI and
> > > possibly some other drivers).  These ports serve as an interface
> > > proxies.
> > >
> > > Let's visualize the action of the library by the following example:
> > >
> > >               Linux             |            DPDK
> > > ==============================================================
> > >                                 |
> > >                                 |   +-------+       +-------+
> > >                                 |   | Port1 |       | Port2 |
> > > "ip link set dev tap1 mtu 1600" |   +-------+       +-------+
> > >                           |     |       ^              ^ ^
> > >                           |  +------+   | mtu_change   | |
> > >                           `->| Tap1 |---' callback     | |
> > >                              +------+                  | |
> > > "ip addr add 198.51.100.14 \    |                      | |
> > >                   dev tap2"     |                      | |
> > >                           |  +------+                  | |
> > >                           +->| Tap2 |------------------' |
> > >                           |  +------+  addr_add callback |
> > > "ip route add 198.0.2.0/24 \    |  |                     |
> > >                   dev tap2"     |  | route_add callback  |
> > >                                 |  `---------------------'  
> >
> > Has anyone investigated solving this in the kernel rather than
> > creating the added overhead of more Linux devices?
> >
> > What I am thinking of is a netlink to userspace interface.
> > The kernel already has File-System-in-Userspace (FUSE) to allow
> > for filesystems. What about having a NUSE (Netlink in userspace)?  
> 
> IMO, there is no issue with the Linux Netlink _userspace_ interface.
> The goal of IF proxy to abstract the OS differences so that it can
> work with Linux, FreeBSD, and Windows(if needed).
> 
> 
> >
> > Then DPDK could have a daemon that is a provider to NUSE.
> > This solution would also benefit other non-DPDK projects like VPP
> > and allow DPDK to integrate with devlink etc.  

With the wider use of tap devices like this, it may be a problem
for other usages of TAP. If nothing else, having to figure out which
tap is which would be error prone.

Also, TAP on Windows is only available as an out-of-tree driver
from OpenVPN. And the TAP on Windows is quite, limited, deprecated,
poorly supported and buggy. There is no standard TAP like interface
in Windows.

TAP on BSD is different than Linux and has different control functions.
Don't remember what the interface notification mechanism is on BSD,
it is not netlink.

So is IF proxy even going to work on these other OS?





More information about the dev mailing list