From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 00A8AA0588; Thu, 16 Apr 2020 19:28:01 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D57831DD8A; Thu, 16 Apr 2020 19:28:01 +0200 (CEST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by dpdk.org (Postfix) with ESMTP id 276B91DD82 for ; Thu, 16 Apr 2020 19:28:01 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id n10so21861285iom.3 for ; Thu, 16 Apr 2020 10:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5mwUQuBX/0IBQuCywL011GlB2Q1ZLdoF+0Y6N4E9kuM=; b=ctoeqj3uGWveOvieXd8LAVsG8j5Q65tdIJxyobhPBL+bkMWhdwZC6dlMLP1PFUhbQ7 iLIXwma5Sp88Zsbzp97zurgTF+WuWapcdHt3RHXK2RvH7JaiqJj4i01Fkt9HGXSbwrP+ MBGuN9JNgv6HCPQXv70R/uNFw10PdaqJB7h8rEJ102mlVFA1b7SzUUbcQRRXG+JFw9xx Mns4E7ulIHfOo1wwupXUvtBz6KkrCNOEOGWRg8IFxYaNghCIKe9bBKK0rb5PEaoLSdPo C+idt+NHbwahALiEb9XhklyMlXFgkmiAWwDYuTWGNYflAWNMbrADqZ6KV+yhs5t5ZG3J 4RwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5mwUQuBX/0IBQuCywL011GlB2Q1ZLdoF+0Y6N4E9kuM=; b=corHxMAz1cDhxy+pOsOzZOJY476CcjwR0sSSek99qH1HIfwDfn9DaMEldaZ8rYfLT1 rYx4EMPPesdxGnErUgbLx34YZKK2EomA7GcRA+O1m4+InlhKYupWZKu5FU/esrGXocHp 4HrarhL6+uIdcNoOJw34cs2bGari4SiUj0HO/WfFU0sDoBurLrqSuxEbdC/8fHopNQDY MeQq0TO/mW0LI9qlvbKN6MaVggZaBHDEzJ44mXvlbBrR5Lr/6E1iyy8x3zFhsKVzO7Nb YnjcJkxMpb09DDuJv8sSf62LOyrSN+0wgsvsYoVbpJ90mLDj7VCauvImwCumbdjuEiR4 hUkw== X-Gm-Message-State: AGi0PuaXzxOn6/VLonHacGjnv9G3DFNe0kQ01dmCRGn3/1d52S95fO+B zStJSFdXNiIFAdU7G7iUqWw8Bito4iamLyYmatE= X-Google-Smtp-Source: APiQypJGRt5Qq9ey46ZLakZLsWQfMK/z2wtIDPwcmupEnTzGs/yJWgOQq3/gUtPs/b35DyvkqfatO9bFEr/uT8BFO1Q= X-Received: by 2002:a02:9a0d:: with SMTP id b13mr31554062jal.60.1587058079123; Thu, 16 Apr 2020 10:27:59 -0700 (PDT) MIME-Version: 1.0 References: <20200306164104.15528-1-aostruszka@marvell.com> <20200416091118.7a4a0bab@hermes.lan> <20200416100433.742b82eb@hermes.lan> In-Reply-To: <20200416100433.742b82eb@hermes.lan> From: Jerin Jacob Date: Thu, 16 Apr 2020 22:57:43 +0530 Message-ID: To: Stephen Hemminger Cc: Andrzej Ostruszka , dpdk-dev Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH 0/4] Introduce IF proxy library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Apr 16, 2020 at 10:34 PM Stephen Hemminger wrote: > > On Thu, 16 Apr 2020 22:19:05 +0530 > Jerin Jacob wrote: > > > On Thu, Apr 16, 2020 at 9:41 PM Stephen Hemminger > > wrote: > > > > > > On Fri, 6 Mar 2020 17:41:00 +0100 > > > Andrzej Ostruszka 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? I dont know about Windows. BSD has a control interface. The library gives abstraction and public API definitions and driver interface. It is up to the implementer to implement driver API for a specific EAL environment. That would help us to not, directly calling Linux specific interface in the DPDK application. > > >