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 32E40A0588; Thu, 16 Apr 2020 19:04:45 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5E2861DD5C; Thu, 16 Apr 2020 19:04:44 +0200 (CEST) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id 287D91DD5C for ; Thu, 16 Apr 2020 19:04:43 +0200 (CEST) Received: by mail-pf1-f193.google.com with SMTP id b8so1926243pfp.8 for ; Thu, 16 Apr 2020 10:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=GXDlziEYBgA/WZDYtW7mJogWUaxv0nIfwk8X5c3shTY=; b=1XmIHaLK0Vm0zuRA80ya5RJxLZ+yyBqeqn07xY5P1fLo98u6BsRZrZov3kUU9JZ46m 0/N+C+gG+REiisYLPEOTyjd7fjnwJYR3qNHyv6Z9WJKayXYAAMpxqTh6MN0E0p+/DCUm FyhELvKZ44qH2aGiU4uT66Eeo0nHfFNrj+o2hAgiLpXSKOVm27xB22kjZEJ9KdthAUrX sAiO2VX790Bn23rGlKtSwCK/jHHBoxQMwbP+dU/+QCLWqrB1RyqWObaoVuyKmRrb0aU9 84sw1SREs+Kbp/XoMufIimIsOGBY+vjZkUv2QkEYaPSZCe+tCmcY0QNrbxcYM4GzBdf9 Og0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GXDlziEYBgA/WZDYtW7mJogWUaxv0nIfwk8X5c3shTY=; b=B3sLL19KO5aL66TriX0ur4UcVzgTDFZ5G+aQTgzGRFfbc5Uaxm9L2+MMTk6qoUyu6N F6qWRFjSXqMAvOP8YXX6eCymiOUCS6kirXtniKyDDNL5TjOiWdZml8Ip7PgKjSO/2j6F cnbF2/4cekzcrQP+scrfKG0GWZsLVu4w+2EYVKSRbBtzKTeg2YJZpb0IMp32CafRBp7g U2ujaIhaBpMjCPVI7FY9aVnu/JaYRU1oWMyMV190cGu80ww6LQbHnk05HwBqPA8k4wui dkS3LQIBQXwuVNCjcekY03GyVcaJ36+6hkNVnWaB6nfmJG/8xzuqvok1xxJw14EM1zSA RrdQ== X-Gm-Message-State: AGi0PuaoPzJ8aBvhnAjSb5tWdCsPvWDktmFMt7A78KOZjbLkEjSPNxfn NBjzCWgTRQ1np0ErrU2HhZNz8Q== X-Google-Smtp-Source: APiQypI4U17bafEnkpOngf9roX2+cSFZGcNIqYxVEfkajEiUFP8NdudTCEsMXijM67C+t4oN6mIeCA== X-Received: by 2002:a62:fccf:: with SMTP id e198mr302476pfh.119.1587056682021; Thu, 16 Apr 2020 10:04:42 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id g25sm17040392pfh.55.2020.04.16.10.04.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2020 10:04:41 -0700 (PDT) Date: Thu, 16 Apr 2020 10:04:33 -0700 From: Stephen Hemminger To: Jerin Jacob Cc: Andrzej Ostruszka , dpdk-dev Message-ID: <20200416100433.742b82eb@hermes.lan> In-Reply-To: References: <20200306164104.15528-1-aostruszka@marvell.com> <20200416091118.7a4a0bab@hermes.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 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?