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 5358BA0588; Thu, 16 Apr 2020 18:49:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 25FDF1DD68; Thu, 16 Apr 2020 18:49:24 +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 833C31D9D9 for ; Thu, 16 Apr 2020 18:49:22 +0200 (CEST) Received: by mail-io1-f66.google.com with SMTP id f3so21771687ioj.1 for ; Thu, 16 Apr 2020 09:49:22 -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=MDSbVn8xEqrahA2FmlLjuWyr+7OqFSk40psam+dsz3c=; b=K6UHn3Au1P90P0E6HYKo+xicA8ah2M2oOsQQt2HlgU0q5bJ7XuRnB8PEPBzSsHS8Z2 X4ZsU3l42MU7WijbZENzsy7/up3fLRaPy3szOpNrHXaU+Wqvp9B4uNJ8rDWUOA/jExle oH+ye4s/B55x/vLdjmiXiLzgnhtJ94K10frgCrCrmzavTiPUgD9gKZrqEtuvRxFtUwsK 3L39SejCZAkDPgtwVawyuvO5NAuT0dCIJZFDSeqsR59U7WPk9IRW7YJro8//l2vLXxmQ KLfPU5ugT/g2J9WNRvJ1K0ziTQ24/3o0JAzAWYRJe9vzvoIpfy6ODDFU1KvX0botuHeC dxIA== 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=MDSbVn8xEqrahA2FmlLjuWyr+7OqFSk40psam+dsz3c=; b=oBe00zlWKcoMwTslTOfemXKYmVjeL5YTvNrHsZDuyn84evQFP5OCWZe/zapLEeHmQD 0hWPwaDn6YnbTtgqm2M1oP7BdarfDV3/9YHvENcLjU7R/oMLkPeXDXtqULc/Lcay0Ewa o+e7ZZMJvXQCYBaoyogQuKViWLTO2kBpwG3mLjpgZ1Y72MK0WkXXbViTeNSaAz9BzVRW iF8GRONygRw1LHuZGYUYRyGNNGM+TGG/j3L+/qN+p2A9zldSzOcxgBQjT9AecgwbOy20 tY2KaSWpdL6QMRd91Zct7nX5F/b/hFk+qGP+vA4c8lf9WkL95ShZfBxJqrmJo66XVSFu q7bA== X-Gm-Message-State: AGi0PuaratGA+uGtvtJ9SLtLjO6Ji8TPe4yKWmnNUwtbfqcB1CTLJ18x MVTRDlSjCg8t3/W8KmGiOrTMIJU49xamjhn66pk= X-Google-Smtp-Source: APiQypJX/LoHla5fSnOVd9RC7o+BiHQF1ZK13Csqi7DA+M0UYQeh3n0maaPOe2XtQd48eVq+6AoOSvomRrBUfhgQELQ= X-Received: by 2002:a02:455:: with SMTP id 82mr31206480jab.112.1587055761778; Thu, 16 Apr 2020 09:49:21 -0700 (PDT) MIME-Version: 1.0 References: <20200306164104.15528-1-aostruszka@marvell.com> <20200416091118.7a4a0bab@hermes.lan> In-Reply-To: <20200416091118.7a4a0bab@hermes.lan> From: Jerin Jacob Date: Thu, 16 Apr 2020 22:19:05 +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 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.