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 8E6B2A0588; Thu, 16 Apr 2020 18:11:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id EEC051D914; Thu, 16 Apr 2020 18:11:30 +0200 (CEST) Received: from mail-pg1-f195.google.com (mail-pg1-f195.google.com [209.85.215.195]) by dpdk.org (Postfix) with ESMTP id 6E2FF1D904 for ; Thu, 16 Apr 2020 18:11:29 +0200 (CEST) Received: by mail-pg1-f195.google.com with SMTP id t11so1857420pgg.2 for ; Thu, 16 Apr 2020 09:11:28 -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=uhg8cUNSUNHM71DCnVm23HDG8r2QoGL1dR9Lo4JmWRc=; b=E7fQyzhfgzRfni4judIH7BO4PrauDliKs25x82AA7n9O0V2b3oMuQGnscUIX7i4H9N jhJH3a2aqAVjhlCaUHTijN+pSR8hR9GT3jrrl/3i4eDXFcmE3X8GBOlDNO6uoJdaF8aQ ZUUfIpQad9H+LmIEf/FJHQ8NGnf7g668bmyRUZpGsl+kuKJ/3MRzS3vVcJaAMXdVNxjJ xoMVjza0GICN+bM2A+ooVt/ha4rYQgYifAeQ8S6vGFjBQwJ+6PinPo8UAt/EjE9NgWbq AjLoYur4eESIq1htHmFsw2DkRErhvYAD1tmKUHn27rZEj5f59fjWl6y8/7bQMYrGobMB JvVg== 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=uhg8cUNSUNHM71DCnVm23HDG8r2QoGL1dR9Lo4JmWRc=; b=SGZJGSk1XnLmMxnk8/2rZER9hJ1hmDsB8N9nOuOeq6lfa6eiT1gHy42+VRQhcw3+CA ROkSsplmxq0N7P/WsaYx+s4dOWayhvd6NV5y6ZA4eQsR+ht6CsanPXjD+S5z2NpdRxcc o5ktgahMHPTKvDTXvFnr5LzbfzsfWgK8tGbtkVORqO0tlN5BWLy+0gcTNGxo94T0/iSQ kHSwB3K1qjGsY2totxo8vaHRDUKfcsj2mofDH96t3JogZHOVGQJ3HuJlXFPwoHSwvneG RWVmatI+a+qeVV467iqHJ3eOn4vpLXBxUWEZut2JjO4me+QR6K82f5ae0DB0gbozhT2N Ua9A== X-Gm-Message-State: AGi0PuaPiQVN+SrZaUjhigr5dmlhjVcQBK0IjVuXTkkVE5LRhb67ltjc Xq+eaWSX71EpinvNzReNSxtaMw== X-Google-Smtp-Source: APiQypLvk3pg5nizAAap8SJuADh7UZCDlIEeFrS8yVzp2gANtrjjlk8qki+T7puiNU8t5+I5aOvZOA== X-Received: by 2002:aa7:8f36:: with SMTP id y22mr33245728pfr.162.1587053487662; Thu, 16 Apr 2020 09:11:27 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id x16sm3463945pfc.61.2020.04.16.09.11.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2020 09:11:27 -0700 (PDT) Date: Thu, 16 Apr 2020 09:11:18 -0700 From: Stephen Hemminger To: Andrzej Ostruszka Cc: Message-ID: <20200416091118.7a4a0bab@hermes.lan> In-Reply-To: <20200306164104.15528-1-aostruszka@marvell.com> References: <20200306164104.15528-1-aostruszka@marvell.com> 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 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)? 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.